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Jelentjük, itt a tavasz! 

Ami áprilisi számunk tartalmát 

illeti, egyetlen fő téma taglalása 
helyett igyekeztünk inkább kör- 
képet adni a Linux alkalmazási 

területeiről. 








Szó esik szuperszámítógépek- 
ről, digitális hangstúdióról, számí- 
tógéppel megvalósított mozgásérzé- 
kelőről, programok optimalizálásá- 
ról, egy grafikai keretrendszerről, 

és egy régi jó adatbázis kezelő új 
változatáról. 

Folytatódik az előző számban indult, 
a jogosultságok központi kezeléséről 
szóló sorozat is. 


Magyar szerzőink is kitettek magukért. 


Dudás Ágnes most a kész programok 
visszafejtésének ,jogkövetkezmé- 
nyeit" tárgyalja, Garzó András pedig 
folytatta az útválasztók működési 
logikájának tárgyalását. Illés Viktor 
Sambáról szóló sorozata immár a har- 
madik részéhez érkezett, Auth Gábor 
pedig a 6. résznél tart a FreeBSD 
bemutatásával. 

Van szerencsénk bemutatni két új 
szerzőnket is. Mindketten középisko- 


lai tanárok, és mindketten a Linux 
iskolai felhasználásáról írtak. 

Szabó Zoltán pingvint klónoz, vagyis 
bemutatja, hogyan telepíthetjük ezt az 
operációs rendszert egy egész gépte- 
remben, viszonylag gyorsan és fájda- 
lommentesen. 

Jászberényi József a levélszemét 
elleni küzdelemre fejlesztett ki egy 
hatékony módszert. Cikkéből meg- 
tudhatjuk, milyen védekezési lehető- 
ségeink vannak, ha a levélkiszolgá- 
lónkhoz ezerszám érkeznek a hibás 
címzéssel ellátott levelek, és ettől 

a teljes levelezés megbénul. Előre- 
bocsátom: a megoldás meglepően 
egyszerű. 

Fábián Zoltánnak ebben a szám- 

ban rögtön két cikke is megjelenik. 
Az egyik a korábbi GIMP-es sorozat 
befejezése, a másik pedig egy olyan 
könyvtárral foglalkozik, amellyel 
könnyen és gyorsan építhetünk 

fel látványos grafikus felhasználói 
felületeket. 


Kellemes időtöltést kíván 
a Linuxvilág stábja! 


0 Kiskapu Kft. Minden jog fenntartva 


0 Kiskapu Kft. Minden jog fenntartva 





Mandrake — Conectiva házasság 
A Mandrakesoft S.A. megerősítette, 
hogy 2.3 millió dolláros részvény- 
ügylettel felvásárolta Dél-Amerika 






Conectiv 
vezető linuxos vállalatát, a brazíliai 
Conectivát. A felvásárlás révén 
a Mandrake Európából Dél-Amerika 
felé tud majd terjeszkedni, valamint 
bővítheti kutatói bázisát is. 

A Conectiva 1995-ben alapult, jelen- 
leg három irodában összesen 60 főt 
foglalkoztat, pénzügyi helyzete 
stabil, elmúlt évi bevétele 2,2 millió 
dollár volt. 

3 www.conectiva.com.br 


PostgreSOL 8.0 
A PostgreSOL Global Development 
Group bejelentette ,a világ legfejlet- 


tebb nyílt forrású, objektumorientált- 


relációs adatbázis-kezelő rendszeré- 
nek" 8.0-s változatát. A PostgreSOL 
méretezhetőségben, a szolgáltatások 


választékában és teljesítmény tekinte- 


tében egyaránt felülmúlja elődeit. 
Újdonságai a komoly kereskedelmi 
adatbázis-kezelő megoldásokat idé- 
zik: a mentési pontok támogatása, 
ezek segítségével a tranzakciókat 
megadott pontra lehet visszaállítani, 
mégsem kell teljes egészében meg- 
szakítani őket; az adott időpontra 
való visszaállítás lehetősége, amelyet 
az adatbázis-kezelő a tranzakciós 
naplók alapján végez el; a táblate- 
rek, amelyek lehetővé teszik a nagy- 
méretű, akár sok GB-os táblák külön 
meghajtóra helyezését, és ezzel hoz- 
zájárulnak a műveletek felgyorsítá- 
sához; valamint a natív windowsos 
változat, mely a Windowshoz kötő- 
dő felhasználók számára a további- 
akban szükségtelenné teszi az 
emulációs réteg használatát, és érte- 
lemszerűen nagyságrendi teljesít- 
ménynövekedést hoz. A PostgreSOL 
mellett döntőknek a kiegészítők 
tájékán is érdemes körülnézniük, 
ugyanis ezek köre is számottevően 
bővült az előző évhez képest, vala- 
mint a tárolt eljárások megvalósítá- 
sára használható programnyelvek 
támogatásán is sokat javítottak. 

3 www.postgresgl.org 
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Harmadik generációra fel! 

A Samsung bejelentette, hogy több 
más gyártó közreműködésével elké- 
szítette első referenciarendszerét 

a harmadik generációs (UMTS) 
hálózatokhoz tervezett, linuxos mo- 
biltelefonokhoz. Az új alaprendszer 
támogatja a következő generációs 
hálózatok szolgáltatásait, mint 

a videohívás és a videofolyamok 
továbbítása, továbbá Java alapú 
alkalmazások futtatására is képes. 





A Cannes-ban rendezett 3GSM World 
Congress kiállításon a Samsung kész 
termékeket is bemutatott, a szintén 
3G hálózatokra csatlakozó, 90x44x25 
mm-es, 1 MP felbontású kamerával, 
belső memóriával és Bluetooth- 
csatolóval ellátott SGH-Z500 jelenleg 
a világ legkisebb 3G mobiltelefonja; 
az SGH-2300 két hangszóróján ke- 
resztül 3D hangot adó zenelejátszó- 
val rendelkezik; míg az SGH-Z130 
egyedülálló, forgatható, szélesvásznú 
kijelzőt kapott. 


Szalonképes PHP 


Az IBM szövetségre lépett a PHP nyel- 
véről ismert Zend Technologies Ltd.-vel 
— céljuk a dinamikus, személyre sza- 
bott tartalmat szolgáltató weboldalak 
fejlesztésének megkönnyítése. 

Az IBM egy Zend Core for IBM nevű, 

a DeveloperWorks oldalról a második 
negyedévtől kezdődően szabadon le- 
tölthető termék formájában fogja kí- 
nálni a PHP-t és saját, Cloudscape nevű 
adatbázisrendszerének nyílt forrású 
változatát. Az IBM lépése fontos lehet 
a PHP szempontjából, hiszen így 

a nagyvállalati piaci szegmensben 

is elismert megoldássá válhat. 


AMD vagy Intel? 


Az AMD egy pillanatra sem szeret- 
né elveszíteni lendületét, központjá- 
ban nemrég nyilvánosan bemutatta 
első kétmagos Athlon 64 processzorát. 
A cég többmagos, 90 nm-es eljárás- 
sal készülő AMD64 lapkáit a ki- 
szolgálóktól kezdve a munkaállo- 
másokon keresztül egészen az ügy- 
félrendszerekig számos területen 
szeretné elérhetővé tenni. Hangsú- 
lyos elem, hogy a végfelhasználók 
számára biztosítani kell a többmagos 
rendszerekre való átállás zökkenő- 
mentességét, ennek egyik jele, hogy 
az újabb lapkák a jelenlegi alaplapi 
foglalatokban és áramellátó egysé- 
gekkel is használhatók lesznek. 
Természetesen szó sincs arról, 

hogy az egymagos processzorok 

egy csapásra eltűnnének a kínálat- 
ból, az AMD elképzelései szerint az 
Athlon 64 és az Athlon 64 FX lapkák 
még jó ideig jelen lesznek, elsősorban 
az otthoni felhasználók gépeiben. 

A nagy rivális, az Intel is tesz arról, 
hogy szerepelhessen a hírekben. 
Már itthon is kaphatók az új, 600-as 
sorozatba tartozó Pentium 4 pro- 
cesszorok, amelyek 1 MB gyorsító- 
tárral ellátott elődjeikhez képest 
immár 2 MB gyorsítótárral rendel- 
keznek, továbbá támogatják az NX 
jelző használatát és a 64 bites memó- 
riakezelő kiterjesztéseket is. 

A Prescott magos Pentiumok lassan 
félelmetessé váló energiafogyasztását 
az új maggal szerelt példányokban 
az órajelet a terhelés függvényében 
változtató SpeedStep megoldás igyek- 
szik féken tartani. A 2 MB gyorsító- 
tárral ellátott processzorok a tesztek- 
ben meglepő módon számottevő tel- 
jesítménybeli előnyt nem tudtak fel- 
mutatni, ellenben áruk 20-30 száza- 
lékkal meghaladja az elődökét. 

Nem árt megjegyezni a Pentium D 
nevet sem, így fogják hívni a jövő 
negyedévben megjelenő kétmagos 
Pentium processzorokat. A meglévő 
775-ös foglalatba illeszkedő lapkák sa- 
játos módon nem fogják támogatni 

a hiperszálas futtatást, vagyis továbbra 
is csak két szál futtatására lesznek al- 
kalmasak - vélhetően az Intel lassan- 
ként akarja csepegtetni a teljesítményt 
a vásárlóknak. A magonként kettő, 
összesen négy szál futtatása egyelőre 
a méregdrága Extreme Edition privilé- 
giuma marad. 











Linuxos kommunikátor-klón 

A német ROAD cég a Nokia kommuni- 
kátoraira emlékeztető linuxos mobilte- 
lefont mutatott be. Az S101 jelzésű tele- 





fon kívülről egyszerű mobiltelefonnal 
látszik, széthajtva azonban egy teljes 
értékű OWERTY billentyűzet és egy 

a lehetőségekhez képest nagyméretű 
kijelző tárul elénk. A telefon 400 MHz- 
es Intel XScale processzort, 64 MB 
RAM-ot és 64 MB Flash memóriát tar- 
talmaz, és a Otopia felületet és személyi 
adatkezelő készletet futtatja. Súlya 210 
gramm, belső kijelzője színes, 640 x 240 
képpont felbontású. Kommunikációs 
szempontból is rendkívül sokoldalú, 
négysávú (850, 900, 1800 és 1900 MHz), 
EDGE-képes GSM-telefon, továbbá ké- 
pes a WLAN, a Bluetooth és az infravö- 
rös alapú összeköttetések kezelésére. 

5 www.road-gmbh.de 


Aki nem tud lemondani róla 

A Win4Lin, Inc. bejelentette új vezető 
terméke, a Win4Lin Pro szállítását. 

A Win4Lin Pro — a Linux rendszermag 


vu Win4Lin 


módosítása nélkül is — teljes értékű 
futtatási lehetőséget kínál Linux alatt 
a Windows 2000 operációs rendszer- 
hez, valamint az alatta üzemelő alkal- 
mazásokhoz, illetve — egyelőre kezdet- 
legesen — támogatja a Windows XP-t is. 
Mivel a Win4Lin virtuális számítási 
környezete a Windows egy teljes, vál- 
toztatások nélküli példányát futtatja, 
esetében, ellentétben a másik ismert 
megoldással, a WINE-vel, a Microsoft 
által kibocsátott frissítések telepítése 
sem okozhat gondot. A Win4Lin Pro 
bevezető ára március végéig 99,99 
USD - ennyi pénzért vásárolhatunk 
egy OEM Windows XP Home Editiont, 
vagy félig hozzájuthatunk a jóval s0- 
koldalúbb VMWare Workstation egy 
példányához. 

3 www.windlin.com 
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Sun újdonságok 

A Sun Microsystems bemutatta 
várhatóan az év közepén megjelenő 
StarOffice 8 irodai csomagjának előze- 
tes változatát, valamint a második 
negyedévre tervezett Java Desktop 
System harmadik kiadását. A Linux 
rendszermag 2.6-os változatára 
épülő operációs rendszer fejleszté- 
se során nagy hangsúlyt kapott az 
eszköztámogatás bővítése, a Microsoft 
Exchange kiszolgálókkal való együtt- 
működés és a microsoftos fájlformá- 
tumok kezelésének javítása. 

A StarOffice fejlesztése során szin- 
tén a Microsoft Office formátumai- 
nak jobb kezelése, valamint az 
általános használhatóság javítására 
fordították a legnagyobb figyelmet. 
A Sun az importálási és exportálási 
szűrők és az adatbázis-kezelés ja- 
vításával, valamint a Visual Basicben 
készült makrók akár automatikus 
átalakításának támogatásával segíti 
az StarOffice-ra való áttérést, illetve 
az áttérés költségének és kockázatá- 
nak csökkentését. 

Ugyancsak a Sun újdonsága lesz 

a még idén várható Trusted Solaris 10 
operációs rendszer. A katonai, kor- 
mányzati hálózatokba szánt operá- 
ciós rendszer egyik érdekessége az 
automatikus, futás idejű ellenőrzés 
lesz, melynek feladata az operációs 
rendszer kódjának futtatás közben 
végzett ellenőrzése. Segítségével, 
digitális aláírások alkalmazásával 
megelőzhetők a jogosulatlan mó- 
dosítások. Hasonló szolgáltatás az 
elsősorban a kémprogramok elleni 
védekezést szolgáló Solaris Secure 
Execution, mely képes ellenőrizni, 
hogy a gyártó általi kiadás óta mó- 
dosították-e az adott programkódot. 
A további finomságok sorában 

a továbbfejlesztett folyamat- és 
felhasználókezelés, a prediktív ön- 
gyógyítás, a Solaris Containers, egy 
új, a PKCS$11 szabványra épülő 
titkosítási keretrendszer, valamint 

a digitálisan aláírt futtatható fájlok, 
könyvtárak és rendszermagmodulok. 
Szintén büszkeségre adhat okot, hogy 
a Solaris előző, 9-es kiadása 15 hónap 
tesztelés után megkapta a Common 
Criteria minősítést; a 10-es kiadás 
vizsgálata pedig folyamatban van. 

3 wwwistaroffice.com 

3 www.sun.comjsoftware/star/ 
staroffice/beta/ 


Második fokozat 

Az LSI Logic az első nagyvállalati 
szintű SATA-II RAID-vezérlőt mutat- 
ta be a LinuxWorld rendezvényen. 

A MegaRAID SATA 300 8x jelzésű 
vezérlő — a SATA szabvány második 
változatának előírásaiból fakadóan — 
elődjeihez képest kétszeres, körülbe- 
lül 3 Gbps sebességet biztosít, miköz- 
ben természetesen a SATA-I-es me- 
revlemezeket is képes kezelni. 

A minden fontosabb operációs rend- 
szert támogató vezérlő érdekessége 
a kaputöbbszöröző, amellyel elméle- 
tileg akár 120 meghajtó kezelésére is 
képes lehet, igaz, a teljesítmény rom- 
lása mellett; továbbá az a kiegészítő 
akkumulátor, amellyel áramkimara- 
dás esetén akár 72 órán keresztül is 
képes megőrizni az adatokat. A ve- 
zérlő ára várhatóan 550 dollár körül 
fog alakulni. 

5 wwwi.silogic.com 


Medgyesi Zoltán 
(mzerettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 
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LIME - A szakma legismertebb egyesülete 


Mindenki Ismeri. Mindenki ismeri? 

Hiába találja ki az ember, hogy egy-két hét alatt 
megváltja a világot, a világ csak nem akar olyan 
gyorsan változni. Lassan frázisokban mondogatjuk, 
hogy a szabad és nyílt érdekcsoportok immár 
évtizedek óta küzdenek, hogy átalakítsák a becson- 
tosodott régi rendszert, ami csak nem akar könnye- 
dén eltűnni. Először csak néhány lelkes egyetemi 
szakember... Ezerszer végigrágtuk már a sztorit. 
Magyarországon , hivatalos szinten" az elsők között 
jött létre a Linux-felhasználók Magyarországi Egye- 
sülete, akkor még egy teljesen más világban. 

Az egyesület igazi szakmai baráti csoportosulás- 
ként indult, a Nyugati Pályaudvar egyik hírhedt 
gyorsétkezdéjében, a kilencvenes évek végén. 
Linux-hívő szakemberek egy kis csoportja alakí- 
totta, kimondottan a Linux ismertségének, elfoga- 
dottságának növeléséért. 

A tagok tehát informatikusok voltak, akik szabad- 
idejükben szervezték az egyesületet. Évekig tartó 
herce-hurca után alakult meg hivatalosan is az egye- 
sület, Péter László elnökségével, de 1998-ban már 
konferenciát szervezett. Az ,öregek" között találjuk 


többek között Czakó Krisztiánt, Magosányi Árpádot, 
Milus Jánost, Regős Szabolcsot, Sári Gábort, Szalay 
Attilát, Varga S. Csabát. 
A lelkes világ addig tartott, amíg áttörésként 
egy tízmillió forintos támogatást nem kapott 
az egyesület. Ehhez kapcsolódóan ugyanis három 
munkát kellett letegyen az egyesület az asztalra: 
Egy magyar nyelvű felülettel rendelkező irodai 
programcsomagot, egy fordítássegítő rendszert, 
valamint egy könyvsorozatot. E három feladatot 
sajnos az egyesület csak hiányosan és nehéz- 
kesen tudta teljesíteni, ami komoly belső feszült- 
ségeket szült. 
A vihar eredményeként nyilvánvalóvá vált, hogy 
az egyesület szerkezete és a célok elérése nincse- 
nek összhangban. Több elnökváltás után a jelen- 
legi elnökség a piac szerkezetét és az egyéb szer- 
vezetek tevékenységét is figyelembe véve igyek- 
szik irányítani az egyesületet. Az érdeklődők szá- 
mára következzen az egyesület céljainak megfo- 
galmazása, valamint az elmúlt év eredményének 
rövid összefoglalója. 

Szy György 





A Linux-felhasználók Magyarországi Egyesülete 

(LME), mint közhasznú egyesület kiemelt célja 

: . a Linux operációs rendszer, és az ahhoz kapcsoló- 
dó programok (elsősorban a Szabad szoftverek) 
felhasználásával, alkalmazásával kapcsolatos isme- 
retek széles körben történő terjesztése, oktatása 
a hazai kutatások, fejlesztések támogatása 
hazai, külföldi és nemzetközi szervezetekkel való 
együttműködés 
a Linux-felhasználók érdekeinek képviselete 
(jelenleg is folyamatosan egyeztünk annak ér- 
dekében, hogy a többség számára elfogadható 
szoftver szabadalmak szülessenek) 


Közhasznú szolgáltatásainkból tagjainkon kívül más 

is részesülhet, (akár Ön is!), így tehettük meg hogy 

jelentős összeggel támogattuk az OpenOffice.org 

honosítását, az FSN.hu több száz GB-tal történő 

diszkbővítését (hozzájárulva a legnagyobb közép- 

európai szabad szoftver gyűjtemény bővítéséhez). 

A idén tovább kívánjuk erősíteni tevékenységünket 

a fenti területeken, különösen az érdekvédelem és 

az oktatás terén. 

A munka oroszlánrészét önkéntesek végzik, műkö- 

dési kiadásaink így is jelentősek. Ha céljainkkal 

egyetért és megteheti kérjük támogassa adója 

1 90-ával egyesületünket! 

Támogatását előre is köszönjük! 

Az LME 2004. évben, az 190-os felajánlásokból 

befolyt összeget a következő célokra használta fel: 
A Fix.tv Linuxportál című műsorának támogatására, 


A számítógéppel megvalósított találmányokról 
szóló direktíva a szoftver szabadalmakat is lehe- 
tővé tevő és ezzel a szabad szoftvereket ellehe- 
tetlenítő változatának elfogadását akadályozó 
munka ügyében szükséges külföldi utazások, és 
a kapcsolódó hazai rendezvények finanszírozása, 
Az egyesület főállású alkalmazotti bérének egy 
részének finanszírozására, 

A fennmaradó részt működési tartalékként tettük 
félre. 


Emlékeztetőül, az eddigi években a következő 190 
felajánlásokat kaptuk: 
2002. évben, első alkalommal 225.067.- Ft 
2003. évben 1.549.026.- Ft 
2004. évben 2.061.032.- Ft 


A támogatás Egyesületünkhöz történő irányításához 
szükséges nyomtatvány PDF formátumban elérhető 
az alábbi címen: 

http:/Avwvw.lme.hu/szabalyzatok/1sz 2004.pdf 


Egyesületünk pontos megnevezése: 
Linux-felhasználók Magyarországi Egyesülete, 
adószámunk: 18095647-2-41 


Köszönjük, ha 2004. évi személyi jövedelem- 
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Mi újság a rendszermag fejlesztése körül? 





A változatkezelési háború még mindig nem csitult el 
teljesen, de azért már csillapodik. Ebben nagy sze- 
repe van annak, hogy a BitkKeeper lényegesen job- 
ban működik mint bármelyik ingyenes vetélytársa, 
valamint, hogy a rendszermag fejlesztők képesség 
kérelmei különös figyelmet élveznek a fejlesztés- 
ben. 2004 novemberében mindössze kétszer került 
szóba valamilyen alternatív megoldás. Először 
Andrea Arcangeli újra bemutatta a t/a-t, más néven 
arch-ot, és bár úgy tűnt több más fejlesztő is figye- 
lemmel kíséri az eszköz fejlődését, az általános né- 
zet szerint még nem skálázható megfelelően ahhoz, 
hogy a rendszermagba kerülhessen. 

Később, egy teljesen másik vita folyamán, felmerült 
a darcs változatkezelő kérdése. Karbantartója, David 
Roundy, bemutatta a rendszermag tárház darcs tük- 
rét. Ez ugyanis a változatkezelő rendszerek Szent 
Grálja, hiszen a rendszermag történetének csak 

a tükre is igen méretes és nehezen kezelhető. 
Egyelőre azonban a Bitkeeper stabilan vezet. 
Mindig jó új dokumentációt látni. Alexander Viro 
mostanában készült el a Cross-compilation 
HOWTO-jával. Mint mondja, egyáltalán nem nehéz 
vagy időrabló dolog a rendszermagot az egyik archi- 
tektúrán fordítani és egy másikon használni. Ő maga 
általában a következő hat architektúrán szokta ellen- 
őrizni a fordítási hibákat: i386, x86 64, sparc32, 
sparc64, Alpha és ppc. Geert Uytterhoeven készített 
pár foltot, amelyekkel mindezt az m68k architektúrá- 
ra is kiterjeszthetjük, de elképzelhető, hogy ez egy 
ideig még pihenni fog, hiszen a jelenleg az megk 
architektúrát nem túl jól támogatja a hivatalos rend- 
szermag forrás. A fejlesztők néhány igen kemény 
problémával kerültek szembe, amelyekre egyelőre 
nem találtak megoldást. 

A 2.6 rendszermag fejlesztési modell továbbra is 
Linus Torvalds/Andrew Morton karbantartói páros 
által végzett átalakításokon és tisztázáson megy 
keresztül. Az új Signed-off-by tag például, új lehető- 
ségeket rejt. Linus mostanában szeretné egyértel- 
műsíteni, hogy ha foltok mennek ide-oda a fejlesz- 
tők között, jobb ha a fejlesztők inkább saját Signed- 
off-by tagjüket helyezik rá, ahelyett, hogy minden 
egyes küldeményük után megtartanának egy-egy 
másolatot. Azt is javasolta, hogy minden változás 
bejegyzéshez csatoljanak egy CC listát, bár, mint 
mondta, ez nem hivatalos dolog, kizárólag informá- 
ciós célokat szolgál és nincs követendő műszaki 
útmutató. Nos, majd meglátjuk meddig tart mindez. 
Ugyanakkor elég nagy csapat fejlesztő elégedetlen- 
kedik amiatt, hogy mint Adrian Bunk mondotta, 

,A 2.6 jelenleg inkább fejlesztői mint stabil rendszer- 
mag." Ezek az emberek úgy gondolják, a 2.7 fejlesz- 


tartás, Alan Cox mégis többször is felajánlotta hogy 
átveszi a 2.6 karbantartását, márpedig ő híresen 
nagy hangsúlyt fektet foltjai stabilitására. A 2.6-ac 
foltsorozata jelenleg rendszermagfejlesztők széles 
tábora számára jelenti a mértékadó rendszermagot. 
Egyelőre se Linus, se Andrew nem mutatta jelét, 
hogy szándékukban állna Alannek átadni a 2.6-ot, 
vagy lassítani szeretnének fejlesztésük ütemén. 
Sőt, a 2.6 fejlesztése mostanában épp ellenkezőleg, 
inkább gyorsulni látszik. 

Mindeközben, Linus a kritikák hatására tovább 
finomítja verziószámozási szokásait. Jelenleg úgy 
gondolja, hogy a 2.6 sorozat esetében minden 
előzetes kiadást rc jellel lát el, így a legutóbbi az 
2.6.10-rc3 jelet kapja. Mindezek mögött ugyanazt 
az egyszerűségre való törekvést sejthetjük, ami 

a 2.5-ös az összes -pre és -rc jelzés elvetésére indí- 
totta, Így végül minden esetben önálló 2.5.x verziót 
adott ki. A stabil/fejlesztői rendszermag váltakozá- 
sának lazulásával, nem tudhatjuk vajon a 2.5-ös 
szabvány megmarad-e a 2.7-ben is. Egyelőre, az 
egyetlen biztos pont a rendszermag fejlesztői mo- 
dell tekintetében az, hogy nincs biztos pont. A Linux 
fejlesztői modell éppen átformálódik, kísérleti stádi- 
umba lépett, felülvizsgálódik, átalakul és bárhogy 

is végződik a dolog, biztosan egészen más lesz 
mind ez idáig volt. 

A 2.4 rendszermag tovább küzd a stabilitásért. 
Marcelo Tosatti többször felülvizsgálta kitűzött cél- 
jait, a teljes lezárástól kezdve néhány fontos új ké- 
pesség elfogadásán kívül minden más elutasításán 
keresztül, egészen egy általánosan engedékenyebb 
elfogadási rendszabályig. Amióta a 2.6 kijött, meg- 
próbálta ,mélyfagyasztani" a 2.4-et, de így, hogy 

a 2.7 nem látható a láthatáron, elég nehéz képessé- 
geket elutasítani a 2.4-ből. Mindig vannak akiknek 

a 2.4 stabilitására van szükségük, de frissebb képes- 
ségekkel; így aztán egyre több és több dolog kerül 
át a 2.6-ból, amelyek aztán megpróbálnak utat talál- 
ni maguknak a 2.4-es forrásfájába. 

A Device Mapper nemrég utasították el végleg, 
ugyanis a 2.4-be illesztéséhez túl nagy változtatá- 
sokra lett volna szükség, ellenben az iswraid (kisebb 
zökkenőkkel), éppen átcsúszott a rostán. A 2.4.28 
után Marcelo újabb elkeseredett kísérletet tett 

a palack bedugaszolására, bár azért hozzátette 

, Az új meghajtók még jöhetnek, feltéve, hogy 

nem törik meg a meglévő beállításokat és jelentős 
mennyiségű felhasználó nyer a felvételükkel. 

Az új meghajtókat pedig olyasvalakinek kell majd 
elbírálnia, aki az adott területen komolyabb tudással 
rendelkezik" — mondta. 








tői rendszermagot a lehető leghamarabb el kell Zack Brown 

ágaztatni, lehetővé téve a 2.6 stabilizálását. Bár : FEE 8 

a fejlesztés egyértelműen jobb móka mint a karban- Cinux Journal 2005. március, 131. szám 
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A világ első vegyes forráskódú vállalati 
rendszere: a Novell Open Enterprise Server 


A Novell NetWare legújabb változata, az Open Enterprise Server egyesíti a nyílt 
és zárt forráskódú rendszerek legjobb tulajdonságait. 


árcius 3-án a Novell Magyarország bemutatta 
az Novell Open Enterprise Servert (OES), amely 


a világ első ,vegyes forráskódú" vállalati rend- 


szere. Az OES egy olyan biztonságos és megbízható hálóza- 


ti szolgáltatáscssomag, amely a NetWare és SUSE LINUX 
Enterprise Server kombinálásával fejlett fájlmegosztási, 
nyomtatási, felügyeleti, csoportmunka és alkalmazáski- 
szolgáló szolgáltatásokat nyújt. 

Az Open Enterprise Server egyesíti a vezető kereskedelmi és 


nyílt forráskódú hálózati platformok előnyeit és emellett egy- 


séges felügyeleti eszközöket, személyazonosság alapú szol- 
gáltatásokat és a Novell teljes támogatási rendszerét kínálja 
a vállalati szintű számítástechnikai igények kielégítéséhez. 
Az Open Enterprise Server minden idők legtöbbet tudó 
NetWare és egyben Linux kiszolgálója. A termék az összes 
főbb hardver- és lapkagyártó cég — például az AMD, Dell, 
HP, IBM és Intel - támogatását élvezi már a piacra kerülés 
időpontjában. 

Az új rendszer fő szolgáltatásai: 


Alkalmazáskiszolgáló 

Fájlkiszolgáló, nyomtatókiszolgáló és tárolórendszer 
Klaszter szolgáltatások 

Rendszerfelügyelet 

Hálózati szolgáltatások 

Személyazonosság kezelése és biztonság 


A Novell OES a Linux, a NetWare és a Windows felhaszná- 
lóinak is kínál előnyöket. 

Komoly értéket jelent azon cégek számára, akik Linux 
kiszolgálóikat a Linux rendszerekben manapság szokvá- 
nyos szolgáltatásokon túl szeretnék bővíteni, hiszen ezeket 
újabb lehetőségekkel egészíti ki. 

Elérhetünk különböző munkacsoportos végfelhasználói 
hálózati szolgáltatásokat, megvalósíthatunk személyazo- 
nosság alapú biztonságot, nagyobb skálázhatóságot érhe- 
tünk el, hatékony felügyeleti eszközök állnak rendelkezé- 
sünkre, és kapunk egy a beállítást megkönnyítő központi 
címtárat és minta alapú telepítési lehetőséget is. 

Nagy környezetekben mindez jelentősen csökkent- 

heti a beállítással, telepítéssel és üzemeltetéssel 
kapcsolatos költségeket. 
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Open Enterprise Server szolgáltatásai 
OES - NetWare § LINUX 





A Novell a NetWare rendszermagot is továbbfejlesztette az 
új NetWare változatban, így az Open Enterprise Server töb- 
bek között hatékonyabb szerverelérést, fürtözést, protokoll- 
kezelést és hardvertámogatást biztosít. 

A termék címtárszolgáltatásai biztosítják a kapcsolatot 
Active Directory és tartomány-alapú rendszerekhez egy- 
aránt, az azonosítási, fájl és nyomtató szolgáltatások pedig 
a megszokott módon teszik lehetővé a felhasználók számá- 
ra a hálózat elérését. 

Bár a Microsoft már nem támogatja a sokak által még hasz- 
nált Windows NT rendszereket, az Open Enterprise Server-re 
való átállás számukra is könnyen megvalósítható, költség- 
hatékony megoldás lehet. 

A Novell által biztosított eszközök megkönnyítik a NetWare, 
Windows vagy Linux felhasználók számára a Novell Open 
Enterprise Server fejlett szolgáltatásaira történő áttérést. 

A felhasználóbarát áttérési és konszolidációs eszközök 
egyszerű és bonyolult szerverkörnyezetekben is leegysze- 
rűsítik és felgyorsítják az adatok régi kiszolgálókról új ki- 
szolgálókra történő átvitelét. A legfontosabb, hogy az új 
szolgáltatások párhuzamosan használhatók a már meglévő 
platformokkal. 

A Novell Open Enterprise Server tavaly december második 
felében került a bétatesztelési fázisba, és mintegy 7000 
résztvevővel a Novell történetének legnagyobb béta-letölté- 
si hullámát indította el. A vezető vírusvédelmi és biztonsá- 
gi másolatkészítő szoftverek gyártói — a BakBone Software, 
CommvVault Systems, McAfee, Syncsort, Trend Micro és 
VERITAS - hamarosan olyan termékeket mutatnak be, 
melyek kiterjesztik az Open Enterprise Server képességeit. 














Pingvinek a bíróságon 


ostanában egyre többször kapnak szárnyra 
HEY] olyan hírek, hogy önkormányzatok, kisebb-na- 

gyobb szervezetek, cégek szeretnének átállni 
a Linux operációs rendszerre. Sajnálatos módon viszont 
szinte semmit sem hallani arról, hogy az átállás hogyan, mi- 
lyen körülmények között zajlott, illetve arról sem, hogy 
azután mik a tapasztalataik az új rendszert illetően, 
mennyire vannak megelégedve a felhasználók az új rend- 
szerrel, vagy egyáltalán csak, hogy mik a tapasztalataik 
a Linux-szal kapcsolatban. Sokan nem csak az átállás kihí- 
vásaitól félnek hanem attól is, hogy utána milyen kompati- 
bilitási problémákkal kell szembenézniük a mindennapi 
munka során, megtalálnak-e minden felhasználói progra- 
mot Linux alatt is. 2001 októberében már egyszer megjelent 
egy cikk, hogy a Vas Megyei Bíróságon Linux operációs 
rendszert használnak többféle feladatra, úgy gondoltam, 
hogy érdemes lenne utána járni annak, hogy mi a jelenlegi 
helyzet, felidézve kicsit az átállás történetét is. Pontosan 
ezért kerestem meg Dologh Ervint, aki a Vas Megyei Bíróság 
informatika osztályvezetője. 


— Gondolom szerver oldalon már régóta használtatok Linux 
operációs rendszereket, amikor először felvetődött a gondolat, 
hogy szabad forráskódú szoftvereket használjatok a munka- 
állomásokon is. De tulajdonképpen mennyi idő telt el a gon- 
dolattól a megvalósulásig, hány számítógépen van Linux 
operációs rendszer, illetve ez a teljes géppark hány százaléka? 

- Nem egészen így volt. Szervereken már valóban 96-tól 
használunk Linuxot, klienseken azért nem, mert egyrészt 
az akkori géppark jelentős része még nem volt , Linux- 
képes", másrészt nem volt elérhető szövegszerkesztő gra- 
fikus felületre. 98 végén, amikor beindult az informatikai 
fejlesztés, már lehetett , magyarított" Applixot szerezni. 

Ez a magyarítás annyiból állt, hogy a menürendszer nagy- 
részt magyar feliratokat tartalmazott, és az előállított szö- 
vegben helyesen jelentek meg az Ő és Ű betűk. Nekünk 
ez akkoriban elegendő is volt, de egy tenderen ilyen prog- 
rammal nem lehetett volna befutni. Tehát a gondolat már 
régen megvolt (az én hivatali gépemen már "94 óta van 
Linux, néhány évvel később pedig már csak Linux). 

A megvalósítás pedig lényegében azonnal megtörtént, 
mihelyt arra lehetőség (pénz) volt. Nagyon fontos ténye- 
ző, hogy nálunk nem volt szükség átállásra valamilyen ré- 
gi rendszerről az újra, mivel a régi rendszer DOS-os gépei 
minden további nélkül illeszkedtek az újba. Persze azt is 
lehet mondani, hogy a megvalósulás" ma is tart, a rend- 
szert folyamatosan bővítjük, alakítjuk, ahogyan azt a lehe- 
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tőségeink megengedik és a környezeti feltételek megkíván- 
ják. És akkor a számok: 2005 január elsején 153 kliens gé- 
pünk tud Linuxot futtatni. Azért nem mondhatom, hogy 
ennyi gépen van Linux, mert diszk nélküli számítógépeket 
használunk, és egy-két helyen még szükség van natív DOS 
betöltésére. Ezen felül van még 1 db Windows 95-ös gép, 
amin kizárólag a GIRO rendszer programja fut (ennek 
nincs linuxos változata), valamint egy Windows 3.1-es gép, 
amit LAN-nal még el nem látott tárgyalóban szoktak hasz- 
nálni. A százalékokat hadd ne számolgassam... 

A szerverek terén már változatosabb a kép, a 11 db linuxos 
szerver mellett működik még egy ALX/RS6000 és egy 
NetWare szerver, valamint néhány hónapja 4 db Windows 
2000 és egy Windows 2003 Server. Ez utóbbiakra a közpon- 
tilag bevezetendő szoftverek miatt lesz szükség. Az AIX- 
en az országos bírósági hálózat levelezőrendszere (Lotus 
Domino) működik, bár mi elsősorban a saját smtpd-postfix- 
gmail-jeinket használjuk, a Domino-ból csak kivesszük 

a belső leveleket. A NetWare pedig az e-directory miatt 
szükséges, noha mi a saját Idap szerverünkről hitelesítünk. 


-— Ha bárkit megkérdeznék arról, hogy vajon miért döntenek 
szervezetek a szabad szoftverek mellett, a kereskedelmi 
szoftverekkel szemben, akkor nyilván mindenki azt vála- 
szolná, hogy a szoftverek árának különbsége miatt. A Vas 
megyei bíróságon is ez volt a legfőbb szempont? Milyen 
egyéb szempontokat vettetek még figyelembe? 

-— Igen, a szoftver ára nagyon fontos szempont. Egyrészt 
azért, mert ténylegesen ugyanazért a pénzért többet 
(sokszor lényegesen többet) lehet megvalósítani, másrészt 
azért, mert az informatikához kevéssé értők is kapnak va- 
lamilyen összehasonlítási lehetőséget. Persze itt is be kell 
tartani a sorrendet: előbb igazolni kell a megfelelőséget, 
és utána rámutatni az árkülönbségre. Nálunk hasonló volt 
a helyzet, azzal a különbséggel, hogy a bíróság elnökének 
látatlanban meg kellett bíznia a bíróság informatikusában. 
(A bíróság informatikusának pedig abban, aki megígérte, 
hogy jó lesz az Applixware :) ) 

Szintén a költség oldalon jelentkezik, de már áttételeseb- 
ben, hogy lehetőség nyílik a hardver-erőforrások jobb 
kihasználására. Eleve vékony klienses úton indultunk el, 
mondván, hogy gyorsan amortizálódó eszközre lehetőleg 
minél kevesebbet költsünk, a pénzünkért tartós értéket 
kapjunk. Ezért a hálózatra és a szerverre összpontosítot- 
tunk, a kliens gépekből pedig kivettünk mindent, amit le- 
het. Így nem pazaroltunk erőforrást például az operációs 
rendszer N példányban való tárolására (a lokális merevle- 
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mezen lényegében csak az lett volna, esetleg swap partí- 
ció), viszont gigabites kábelezést készíttettünk, és tisztán 
switchelt hálózatot. Ez 1998-ban még nem volt olyan 
természetes, mint manapság. 

Később aztán lettek egyéb hasznos eredői is a választás- 
nak. Egy évvel ezelőtt be tudtunk szerezni elegendően 
nagy teljesítményű szervereket ahhoz, hogy a szoftverek 
futtatását a kliensekről átterheljük a szerverekre. Ezáltal 
jelentősen csökkent a hálózati sávszélesség-igény, de ami 
még fontosabb, hogy a régi, egyébként már selejtezésre 
érett gépek terminálként újra használhatók lettek, majd- 
nem olyan használati értékkel, mint az újabbak. Illusztrá- 
cióként: egy 7 éves AMD K6/300-as gépnél a klikkeléstől 
számítva 4 másodperc alatt elindul az OpenOffice, 

a gyorsindító funkció nélkül! Természetesen ha már 
többen is használják a szövegszerkesztőt, ez az idő még 
tovább csökken a memóriába olvasás idejével. A Megyei 
Bíróság szombathelyi épületeiben a felhasználók asztalán 
virtuálisan" 64 bites duál-opteron gép ketyeg. Bírósági 
viszonylatban azért ez nem az átlagos szint. 

A harmadik fontos dolog az, hogy önállóan tudunk új ké- 
pességeket adni a rendszerhez. Például nálunk már régen 
"alanyi jogon" járt az e-mailezés lehetősége mindenkinek, 
aki accounttal rendelkezett, amikor hivatalosan" még csak 
megyénként 14 db licencet osztottak ki a bíróságoknak 
egy olyan levelezőrendszerhez, amelyet azóta már ki is 
dobtak. De van aktuálisabb példám is. A már említett, be- 
vezetni kívánt Windows-alapú szoftvereket nálunk a fel- 
használók dedikált szerveren fogják terminálos üzemben 
futtatni. Ezeket a szervereket ezért tűzfallal le tudjuk vá- 
lasztani a belső hálózatról, csak a terminál- és az adatbázis 
elérést engedélyezve. Ráadásul 1 db terminálszerver li- 
cenc feleannyiba kerül, mint egy OEM Windows XP, tehát 
a megnövekedett biztonság mellé bónuszként az olcsóbb 
bővíthetőséget kapjuk. 

És végül, de nem utolsó sorban meg kell említenem 

a linuxos közösséget, amely főleg a kezdeti időkben igen 
komoly támaszt jelentett. 


Az általad felsorolt szempontok mennyire valósultak meg? 
Tehát az átállás beváltotta-e a hozzáfűzött igényeket? Eset- 
leg van olyan amit nem? 

Szerintem az elvárt dolgok bejöttek, sőt, az idő múlásával 
egyre inkább megmutatkozik a nyílt forráskód stratégiai 
előnye. Persze senki ne gondolja, hogy küszködés, kínló- 
dás, harc nélkül lehet külön úton járni. Sajnos folyamato- 
san történnek környezetünkben olyan dolgok, amelyek 
hallatán az informatikában járatos, ám gyanútlan személy 
rögtön a kollégák otromba tréfájára gyanakszik. Pedig tré- 
fáról szó sincs. Néhány negatív hatású intézkedést éppen 
a Linux segítségével sikerült közömbösíteni. 


- Az emberek általában félnek a változástól, és nehezen vehe- 
tőek rá új dolgok használatára, aki nem mozog annyira ott- 
honosan az informatikában, annak gondolom még nagyobb 
nehézséget okozott az átállás. Hogyan támogattátok a fel- 
használókat átállás előtt, közben, és utána? 

Ebben megint csak szerencsénk volt. Nem volt szükség 
komolyabb áttérésre, mert a korábbi rendszer elsősorban 
DOS-Clipper alkalmazásokat és WinWord 2.0 szövegszer- 
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kesztőt adott a felhasználóknak. A DOS-os programokat 
továbbra is ugyanúgy lehetett használni, a szövegszer- 
kesztőt pedig amúgy is frissíteni kellett volna. Nem aka- 
rok senkit sem megbántani, de nálunk nem voltak 
WinWord bűvészek vagy Excel zsonglőrök, akik egér nél- 
kül használták volna a gépüket. Az új rendszer a régihez 
képest gyorsabb volt, mindenki színes monitort kapott, és 
megmutogattuk, hogy a szükséges műveleteket hogyan 
lehet elvégezni, az új menürendszerben mi hol van. 

A tanulási folyamat az éles használat közben is folyama- 
tosan tart, a felmerülő speciális formázási igényeket 
együtt próbáljuk megcsinálni, így jobban is rögzül. 

A kezdeti applixos idők után már komolyabb feladat 

volt a StarOffice bevezetése, de szerencsére a két rend- 
szer békésen megfért egymás mellett, így mindenki a saját 
maga számára kedvező időpontban válthatott. 

Azoknál, akik írógép mellől ültek a számítógéphez, maga 
a számítógép, annak kezelése jelentett problémát. Az 
újonnan felvett dolgozók többsége ma már úgy érkezik, 
hogy használt már számítógépet, az esetek többségében 
persze valamilyen Windows verziót. Eleinte némelyik rek- 
lamál, hogy nálunk is miért nem az van, meg, hogy miért 
nincs floppy meg CD olvasó a gépben, de ők is hamar 
megnyugtathatók. 


Sajnos általános probléma, hogy a Linux operációs rendsze- 
rekhez nincs annyi felhasználói szoftver, ezért esetleg van- 
nak-e olyan feladatok, melyeket nehézségek árán lehetett 
megoldani, illetve meg sem tudtátok oldani őket? 

A bíróságokon használt szoftvereket három csoportba 
sorolhatjuk aszerint, hogy mennyire általános célúak. 
Vannak olyanok, amelyek bármely irodában megtalál- 
hatók, például szövegszerkesztő-táblázatkezelő-stb. 
csomagok, vannak szűkebb (például jogászi, pénzügyi) 
körben használatos programok, és vannak kimondottan 
bírósági célszoftverek. Az első csoporttal nincs különö- 
sebb gond, kompatibilitási problémák ugyan akadnak, 

de azokkal együtt lehet élni, esetenként lehet ilyen 

vagy olyan közbülső adatformát találni. Elvileg a har- 
madik csoporttal sincs gond, hiszen csak azt kellene 
mondari, hogy olyan szoftvert kell csinálni, ami multi- 
platformos, vagy eleve platformfüggetlen. Jelenleg azon- 
ban az eredeti elképzelésekkel szemben tisztán Win32-es 
szoftverek készülnek, inkább adtak mellé szervereket is, 
hogy legyen min futtatni... Úgy tervezzük, hogy a fejlesz- 
tési hullámverések csillapultával itt helyben megkezdjük 
a szoftverek linuxos megfelelőjének elkészítését. Vissza- 
utalva az egyik korábbi kérdésre: ez is egy járulékos 
előny, rengeteg eszköz van a kezünkben a saját szoftverek 
elkészítéséhez. A második csoporttal van igazán baj. 
Ezeket a szoftvereket jelenleg szinte csak Win32 plat- 
formra készítik, a Kerszöv CD-Jogtára egy szabályt erősí- 
tő kivétel. Sok esetben nem is tudni, hogy miért nem 
publikus az ilyen szoftverek forráskódja, hiszen sok- 

szor a mellé csomagolt, rendszeresen frissített adatok 

a lényegesek. Az, hogy egy magáncég ilyesmire nem fi- 
gyel, még elfogadható. De egy közcélokat szolgáló állami 
intézménynél, mint amilyen például az APEH vagy 

a KSH, kötelesek lennének figyelni a versenysemlegesség- 
re. Hogyha majd elektronikusan kell adatokat szolgáltas- 











sunk, mi lesz? Vagy ezek az intézmények jogosultak arra, 
hogy előírják, hogy milyen rendszert kell használni az 
ügyfeleiknek? 


- Ahogyan említetted, hogy legkisebb megyeként nehéz külön 
úton járni, bennem rögtön felmerült az, a kérdés, hogy 
mennyire tudtatok így beilleszkedni a bíróságok rendszeré- 
be? A mindennapi munka során mennyi plusz költséget je- 
lent, hogy dokumentumokat, kapott fájlokat konvertáltok 
Linux alá, majd vissza, illetve, hogy wine-t használtok? 

— Először is: wine-t nem használunk. Egyszer-kétszer próbál- 
tuk, de valahogy nem az igazi. Ami pedig a kétféle rend- 
szer össze-nem-iilleszkedését illeti: régebben több volt ebből 
a gond, manapság már kevesebb. Álláspontom akkor is az 
volt, ma is az: ha a kirakós játék két darabja nem passzol 
össze, azért nem lehet csak az egyik vagy csak a másik da- 
rabot hibáztatni. Az összekapcsolódás egy kölcsönösséget 
feltételező folyamat. A konverziókkal kapcsolatosan a ma- 
gunk részéről mindig valamilyen szabványos formában 
igyekszünk továbbítani anyagokat, és a partnereinktől is 
ezt várjuk. Ha olyan Excel táblát kapunk pl., ami agyon 
van makrózva, ráadásul jelszóval le is védik, akkor a küldőt 
megkérjük, hogy ezt vegye ki. Ebből általában még nem 
volt probléma. Abból már igen, hogy az általunk CSV for- 
mában küldött táblázatot sehogyan sem tudták beolvasni 
Excelbe, mert a mezőelválasztó nem az alapértelmezett "/ 
karakter volt, hanem a " [/... A lényeg és a tapasztalat min- 
denesetre az, hogy kölcsönös jó szándék mellett a problé- 
mák megoldhatók. A Linux nem egy földöntúli csoda, lehet 
olyan feltételeket előírni és az utolsó vesszőig megkövetel- 
ni, amelyeket Linuxszal ma még nem lehet teljesíteni. 

Ez módot ad arra, hogy hatalmi szóval a Linux létalapját 
meg lehessen semmisíteni. De ha valahol ez a helyzet, 

ott más, komolyabb baj is van, ott ez már csak tünet. 
Bármilyen informatikai rendszert is használnak valahol, 
biztos, hogy a használat közben felmerülnek kisebb-na- 
gyobb gondok, problémák. Ha egy cégnél úgy döntenek, 
hogy áttérnek nyílt forráskódú rendszerre, nem kevesebb 
lesz a gondjuk, hanem más jellegű. Megszűnik a rettegés 
a vírusos levelektől, cserébe alkalmanként molyolni kell 

a dokumentumkonverzióval. Lényegesnek tartom azon- 
ban, hogy a felmerülő problémák megoldása kisebb költsé- 
get de komolyabb hozzáértést kíván, és nagyobb döntési 
szabadságot ad. 


Gondolom sok tapasztalatotok gyűlt össze az átállást 
követően, van esetleg valami amit mindenképpen másképp 
csinálnál? 

- Nem, azt hiszem nem. Az induláskor a szövegszerkesztő 
kivételével a többi szoftverkomponenst már leteszteltem, 

a saját munkaállomásom és a már linuxos szerver segítsé- 
gével ki tudtam próbálni a működőképességet. Innentől 
kezdve már csak a matematika és a szukcesszív approxi- 
máció szabályait követve számolgatni kellett, hogy a ren- 
delkezésre álló pénzből hány munkahelyes hálózat jön ki. 
A felhasználók részéről nem számítottam ellenállásra, nem 
is volt. A bíróság elnöke pedig rábólintott. (Később emiatt 
többször kerülhetett kényelmetlen helyzetbe, nem könnyű 
legkisebb megyeként külön úton járni.) Az igazsághoz 
hozzá tartozik, hogy Veszprém megyében is hasonló rend- 
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szer készült el és működött évekig, de végül más kézbe ke- 
rült az informatika irányítása és megfelelő gondoskodás 
hiányában a linuxos rendszer szép lassan eltűnt. 
Bővüléskor pedig már szinte magától ment minden. 

(Na jó, azért voltak izgalmas pillanatok :) ) Ha N darab 
gépre kaptunk pénzt, akkor rögtön konvertáltuk 2N darab 
CD-től, merevlemeztől, floppytól operációs rendszertől 
megfosztott gépre, esetleg lézernyomtatóra, mostanság 
lapos monitorra, mikor mire volt éppen szükség. A szállító 
céggel jó kapcsolatot sikerült kialakítani. Mi is jól járunk, 

a cég is többet kap (nem sokkal, mert nincs miből) mert 

a konverziónál mindig marad egy kis hiány. 


-— Hogyan érdemes nekikezdeni egy ehhez hasonló átállásnak, 
mit javasolsz azoknak a szervezeteknek, vállalatoknak, 
akik hasonló lépést fontolgatnak? 

Nyilván nem lehet egy általános sémát adni az áttérésre. 
Mindenesetre az biztosnak látszik, hogy az informatikusok- 
nak és a vállalat vagy szervezet vezetőinek együttes akara- 
ta szükséges. Az informatikusoknak nyilván érteniük kell 

a Linuxhoz, a vezetőknek pedig - és ez az, ami hihetetlenül 
nehezen megy - be kell látni, hogy ami ingyen van az lehet 
jó, sőt, jobb, mint amit pénzért kaphat. Személyesen ta- 
pasztaltam több esetben, hogy a döntéshozóval való meg- 
beszéléskor már nem volt egyéb érve a nyílt forráskóddal 
szemben, csak annyi: Ezt nem hiszem el. Ez nem lehet 
igaz. Ebben valami trükk van. Ez így nem működhet. 

Az áttérés: küzdelem. Küzdelem a rögzült szokások, néze- 
tek, hiedelmek megváltozásáért. Ha van közvetlen anyagi 
nyereség (például amúgy is frissíteni kellene operációs 
rendszert, szövegszerkesztőt, de ezt szinte ingyen oldjuk 
meg szabad szoftverekkel), akkor ez erőt adhat, ezért szá- 
momra ésszerűnek tűnik a frissítés és az áttérés összekap- 
csolása. Hasonlóan, ha valahol új rendszer épül ki, rögtön 
nyílt forráskódú rendszerrel indulni könnyebb, mint menet 
közben váltani. Jelenleg a közszférában persze automatiz- 
musok vannak, az illetékes döntéshozók fejében föl sem 
merül ennek lehetősége. Végül is egyszerűbb adóztatni, 
mint felvállalni egy szokatlan újdonságot. 

Ha azonban a fogadókészség a vezetők részéről is megvan, 
ha nem is sima, de nagyobb buktatók nélküli lehet az út. 
Erre jó példa a Novell, ahol példamutató módon tették meg 
ezt a lépést. Könnyű nekik — mondhatnánk - hiszen az 
egész cég tele van informatikusokkal, nekik ez semmi. 

— Tévedés. Egy csökönyös informatikus rosszabb tíz buta 
adminisztrátornál. Másik példám a Fővárosi Bíróság ame- 
lyek fő tevékenysége nem számítástechnikai jellegű, tehát 
az ottani informatikusok nem a dolgozók derékhadát alkot- 
ják, és a vezetők körében az egy főre jutó informatikai is- 
meretek mennyisége érthető módon alacsonyabb mint 

a Novell esetében. De az informatika felkínálta a nyílt for- 
ráskód nyújtotta előnyöket, a vezetés pedig nem X vagy Y 
szoftverkereskedő cég szakértőiben" bízott meg, hanem 
saját embereiben, és — a lehetőségeket mérlegelve — belátta, 
hogy hosszú távon ez a járható út. Nincs zsákutca, nincs 
kidobott pénz, nem kell a millióféle licenc kalkulálásával, 
nyilvántartásával, frissítésével kínlódni. 

Így hát nekiláttak, és én sok sikert kívánok a munkájukhoz! 


Az interjút készítette Horváth Ernő 
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BladeRunner Cluster-in-a-Box 
A Penguin Computing bejelentette 
BladeRunner Cluster-in-a-Box ki- 
szolgáló rendszerét, mely penge 
kiszolgálókat, 
Ethernet kapcsoló- 
kat, tároló alrend- 
szereket, felügye- 
leti szoftvert és 
fürtkezelő operációs rendszert fog 
össze egyetlen 4 egység magas 
házba. A BladeRunner fürtre előte- 
lepítik a Scyid Beowulfot, ez egy 
kifejezetten fürtkezelésre fejlesztett 
terjesztés, segítségével egyetlen 
pontból végezhető el a telepítés, 
a bejelentkezés és a felügyelet. 
A mester csomópontban kettő da- 
rab 2.4 GHz-es Xeon LV processzor 
található, 2 GB PC2100-as DDR 
RAM, valamint egy 60 GB-os, 2,57- 
os IDE merevlemez. A 11 darab 
szolga gépben szintén két-két Xeon 
LV processzor és PC2100-as DDR 
RAM üzemel, ám ezek PXE-képes, 
merevlemez nélküli csomópontok. 
A BladeRunner rendszerek további 
4 egység magas házak hozzáadá- 
sával és a beépített Ethernet kap- 
csolók csatlakoztatásával akár 42 
egységnyi, 240 processzort tartal- 
mazó összeállítássá bővíthetők. 
www.penguincomputing.com 


Outblaze-SME 

Az Outblaze-SME egy értéknövelő 
viszonteladók számára tervezett 
elektronikuslevél-kezelő alaprend- 
szer, célközönségét a kis- és 
középvállalkozások (small- to 
medium-sized enterprise—- SME) 
alkotják. Az Outblaze-SME felügye- 
leti és együttműködést segítő esz- 
közei révén az SME-k tárolóhelyet 
vásárolhatnak, illetve webes felü- 
leten keresztül elektronikus levele- 
zési, naptárkezelési és fájltárolási 
szolgáltatásokat érhetnek el. 
Együttműködést segítő eszközei le- 
hetővé teszik, hogy a munkatársak 
naptárakat, névjegyeket és fájlokat 
osszanak meg egymással, az SME 
rendszergazdák pedig maguk ve- 
hetik kézbe a felhasználói fiókok, 

a tárolóhely, a csoportlisták és 

a közös címtárak felügyeletét. Az 
Outblaze-SME a POPS, az IMAP4A 
és az SMTP protokollt egyaránt 
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támogatja, illetve a levelek elérését 
webes felületen keresztül is bizto- 
sítja. Az Outblaze-SME-hez az 
Outblaze Sentry nevű vírusvédelmi 
és levélszemétszűrő szolgáltatása 
is igénybe vehető. 
www.outblaze.com 


Xandros Desktop 3 

Asztali és hordozható gépekre egy- 
aránt elérhetővé vált a Xandros 
Desktop OS 3-as változata. A har- 
madik kiadás a 2.6.9-es Linux rend- 
szermagra épül, és a KDE 3.3 
testreszabott változatát foglalja ma- 
gába. A legújabb kiadás újdonságai 





között a Xandros File Manager alatt 
fogd és vidd jelleggel végezhető 
DVD-rás, a Xandros Personal 
Firewall, az Intel Centrino termék- 
család és vezeték nélküli hálózati 
csatolóinak támogatása, a felhasz- 
nálói fájlok önműködő titkosítása, 
a PPTP VPN-ek biztonságos eléré- 
se, a CrossOver Office 4. 1-es válto- 
zata és a Xandros Networks frissí- 
téseire a figyelmet önműködően 
felhívó értesítők említhetők. 

A Xandros Desktop 3-as változata 
lehetővé teszi, hogy a felhasználók 
fogd és vidd módszerrel bárhon- 
nan bárhová másoljanak, mozgas- 
sanak fájlokat, ide értve a windovv- 
sos hálózati megosztásokat az 
FTP-helyeket is. Ugyancsak a fel- 
használók kényelmét és biztonsá- 
gát szolgálja az önműködő vírusvé- 
delem és levélszemétszűrés is. 
www.xandros.com 


Kiwi T1x0 

Az EmperorLinux Kiwi T1x0 jelzés- 
sel új, a Sony T140-es, T150-es, 
T160-as és T170-es VAIO modell- 
jeire épülő munkaállomásokat 
mutatott be. A mindössze másfél 
kilogramm súlyú hordozható gép 
1280 x 768 képpont felbontású, 
10,6"-os, szélesvásznú, az X által 
natívan kezelt LCD-képernyővel 
rendelkezik. A Kiwi T150 Fedora, 
Red Hat Enterprise, Debian, 


Slackware és SuSE minősítéssel 
rendelkezik. Mindegyik Kíwiben 1,1 
GHz-es, 2 MB gyorsítótárral ellátott 
Pentium-M 733 processzor találha- 
tó, továbbá 512-1024 MB RAM, 40 
GB-os merevlemez és CDRW-DVD- 
vagy DVD-RW-meghajtó. Az 
összes Kiwi teljes értékűen támo- 
gatja az 1280x 768 képpontos, 24 
bites színfelbontású módban futó 
X-et. A lapkakészlet i855gm; a há- 
lózati kapcsolatok létrehozására 
10/100 Mbps sebességű vezetékes 
Ethernet csatoló, 11-54 Mbps se- 
bességű 802.11 a/b/g Wi-Fi 
Ethernet csatoló, USB 2.0 és IEEE 
1394 FireWire vezérlő használható; 
a bővíthetőséget CardBus foglalat, 
a kényelmet pedig az ACPI alapú 
hibernálási lehetőség garantálja. 

A Kiwi minden változatához jár 

az EmperorLinux ajándékcsomag, 
valamint az ingyenes, telefonon 

és elektronikus levélben igénybe 
vehető támogatás. 
www.emperorlinux.com 


DiskOnChip H1 

Az M-Systems új DisKkOnChip csa- 
ládot mutatott be, a zenei és moz- 
góképkezelő készülékekbe szánt 
termékvonal tagjai akár 8 GB-os 
tárolókapacitással 

is rendelkezhet- e 
nek. Az elsőként s? gy 
megjelenő 4 GB- BD az 
os DiskOnChip iii 

H1T 90 nm-es MLC NAND Flash és 
x2 technológiával készül, az M- 
Systems TrueFFS Flash fájlrend- 
szerét használja, mellyel egyetlen 
lapkán is lehetségessé válik nagy 
mennyiségű MF3 vagy egyéb 
multimédiás fájl kezelése. 

A DiskOnChip H sorozat hagyomá- 
nyos, NOR-kompatibilis csatolófe- 
lülettel rendelkezik, így bármilyen 
mobil lapkakészlettel használható. 
A HT minden fontosabb - Symbian 
OS, Windows Mobile, Palm OS, 
Nucleus és Linux — mobil operáci- 
ós rendszert támogat, és minden 
jelentősebb általános vagy multi- 
médiás célú processzorral képes 
együttműködni. 

m-systems.com 
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Tervezetkezelés a WebCollab segítségével 


Nyílt forrású, még felfedezésre váró gyöngyszem, mely a tervezetek állapotadata- 
it és a hozzájuk kapcsolódó fájlokat könnyedén áttekinthető, webes felületen teszi 
elérhetővé. Próbáljuk ki, vajon illeszkedik-e munkavégzési szokásainkhoz! 


álózati tanácsadóként sokszor dolgozom együtt ki- 
Ki sebb csapatokkal informatikai tervezeteken. Bármi- 

lyen jellegű is a munka, mindig számtalan kérdést 
kell egyeztetnem más tanácsadókkal, az ügyfelekkel, adat- 
kereskedő cégekkel és az irodai munkatársakkal. Folyama- 
tosan szükségem van valamilyen megoldásra, amely révén 
naprakész információkkal tudom ellátni munkatársaimat, 
és ez sokszor fájlok, feljegyzések megosztásával jár. Korábbi 
munkahelyemen megtanultam, hogy a Microsoft Exchange 
nyilvános mappái és a Microsoft Project együttese kiválóan 
alkalmazhatók erre a célra. 
Bár a Microsoft termékei szinte minden számomra szüksé- 
ges lehetőséget biztosítanak, vannak bizonyos korlátaik. 
Először is, az Exchange/Project párosítás egy zárt megoldás, 
tudását elsősorban a Microsoft Windows használói tudják 
kiaknázni, és ők is inkább akkor, ha azonos szervezetbe 
tartoznak. Másodszor, a Microsoft Exchange csomagja a leg- 
több kisvállalkozás számára túlságosan drága. Harmadszor, 
bár az MS Project és az egyéb Gantt-grafikonkészítő alkal- 
mazások de facto szabványnak tekinthetők a tervezetkeze- 
lés területén, inkább nagyobb léptékű munkák átfogó keze- 
lésére alkalmasak, például építkezések levezérlésére. Végül, 
egyesített fájltárolót és tervezetállapot-kezelést akartam, így 
a tervezetek végigvitele akkor sem okoz gondot, ha a mun- 
katársak különböző szervezetekből érkeznek. 
Teljesen véletlenül botlottam bele a WebCollabbe 
a SourceForge oldalán, és rendkívül megörültem neki. Készí- 
tői szerint a WebCollab egy ,az együttes munkát segítő, 
web alapú rendszer tervezetekhez és tervezetkezeléshez; 
a WebCollab könnyen használható, közös munkavégzésre 
bátorítja alkalmazóit. A program kényelmesen kezelhető, 
funkcionális megjelenésű és biztonságos, miközben haszná- 
lata a legkevésbé sem megterhelő, és komolyabb grafikus 
teljesítményt sem igényel." 
Igazolhatom, ez mind igaz. A program készítői a tervezés 
során a használhatóságot a forma elé helyezték, a felület ki- 
válóan átlátható, használata és működése egyszerű és gyors. 
A WebCollab ideális megoldás kisebb munkacsoportok szá- 
mára, amennyiben bennük az adatok áramlásának jellege 
viszonylag állandó. Nem egyszerűen egy többfelhasználós 
tennivalók listája, hanem minden tervezethez hozzárendel 
egy feladatlistát, határidőket, színkódolt előrehaladás-mérő- 
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1. ábra A rendszergazdák erről az oldalról hozhatnak létre új 
felhasználói fiókokat. A felhasználó az itt megadott címre kapja az 
állapotváltozásokról értesítő elektronikus leveleket. 


ket, fontossági szint beállításokat, fórumot és fájlfeltöltési 
részt. Ha valamelyik feladat állapota megváltozik, akkor 
lehetőség nyílik az érintett felhasználók vagy csoportok 
elektronikus levélben való értesítésére. A fórumokon folyó 
viccelődések, a fájlcserék és az állapotjelentő elektronikus 
levelek összességével a WebCollab valóban interaktív kör- 
nyezetet teremt a tervezetek kezeléséhez. A vezető hasz- 
nálhatja a feladatok kiosztására, majd az alkalmazottakkal 
folyamatos párbeszédet fenntartva bármely pillanatban 
tisztában lehet a munka előrehaladtával; eközben egy pilla- 
natra sem kell kilépnie a program keretei közül. 

A WebCollab kínál néhány nagyszerű szolgáltatást, emellett 
telepítése is egyszerű, használatát pedig gyakorlatilag nem 
kell tanulni. Kisebb irodai környezetben vagy különböző 
szervezetekbe tartozó munkatársak részvételekor nagysze- 
rű választás. Én például a WebCollab segítségével tájékozta- 
tom ügyfeleimet a nekik végzett munkám folyamatáról, 

de rajta keresztül tartom a kapcsolatot a velem együttmű- 
ködő mérnökökkel és technikusokkal is. 


Rendszerkövetelmények és felépítés 

A program felhasználói felülete Apache és PHP alapú, hát- 
térrendszere pedig egy adatbázis. Ha a PHP alapú oldalak 
elérhetőkké váltak a webkiszolgálón keresztül, akkor 
böngészőprogram és megfelelő jogosultságok birtokában 
bárki hozzáférhet a WebCollabhez. 

Szerintem a legjobb összeállítás a Linux — Apache — MySOL - 
PHP, de bármely az Apache és a PHP futtatására alkalmas 
operációs rendszer megfelel, és a MySOL helyett Postgrest is 
választhatunk. Ha szükséges, az adatbázist egy másik kiszol- 
gálóra is helyezhetjük. Jelenleg egy 500 MHz-es órajelű 
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Pentium III processzorral, 256 MB 
memóriával és 20 GB-os merevlemez- 
zel felszerelt munkaállomást használok 
erre a célra, de a körülbelül 15 felhasz- 
náló által okozott terheléshez ez alig- 
hanem még sok is. A program gond 
nélkül futtatható egy régebbi, de még 
munkaképes gépen, illetve meglévő 
kiszolgálóra is bátran telepíthetjük, 
nem fog komoly terhelést okozni. 
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Felhasználók és csoportok 

A program bármely részének elérésé- 
hez felhasználónevet és jelszót kell 
megadni, és ettől függ, hogy mely 
tervezeteket tekinthetünk meg és 
melyeket módosíthatunk. Amint más 
rendszerekben is, csak a felügyeleti 

al felhasználóknak van joguk a felhasz- 
nálói fiókok hozzáadására vagy törlé- 
sére. Tervezet vagy feladat tulajdono- 





A személyes érzelmeket félretéve is 
Windows vagy éppen Mac OS helyett 
inkább a Linuxot javaslom, mégpedig 
könnyű használata és távfelügyelet- 
ének biztonsága miatt. A WebCollab 
telepítéséhez jogot kell szereznünk 
adatbázis létrehozására, illetve a WebCollab könyvtárán belü- 
li jogosultságok némelyikének megváltoztatására. Attól füg- 
gően, hogy mekkora fájlfeltöltési forgalomra számítunk, né- 
hány száz MB-nyi pluszterületet biztosítsunk webes könyv- 
tárunkon belül. Az egyes fájlok mérete legfeljebb 2 MB lehet. 
Az Apache és a MySOL üzembiztosságával nincs semmi 
gond, és általában véve a PHP kód minőségében sem talál- 
tam kivetnivalót. Az viszont tény, hogy vállalati szintű hasz- 
nálatra a WebCollabet nem ajánlanám. Felhasználói tábora 
viszonylag kicsi, komolyabb terhelés alatt még nem bizonyí- 
tott. A legtöbb vállalat a támogatásra is nagy hangsúlyt fek- 
tet, amikor kiválasztja alkalmazásait. A WebCollab jelenleg 
egy apró, nyílt forrású tervezet, így nem számíthatunk arra, 
hogy a nap bármely pillanatában rendelkezésünkre állna 
egy tetszőleges helyzetet megoldani képes programozó. 


Telepítés 

A telepítés végletesen egyszerű, nekem tíz percig sem tar- 
tott. A terjesztésemhez tartozó alap Apache-ot, PHP-t és 
MYySOL-t tettem fel, ezek tökéletesen működtek is. A Linux 
kezelésében járatlanok számára a legnehezebb a MySOL 
alatti új felhasználó létrehozása lesz, akinek megfelelő hoz- 
záférést is kell adni az adatbázishoz. Ettől eltekintve a cso- 
mag telepítése még egy kezdő Linux-felhasználó számára 
sem jelenthet gondot. 

A telepítést kétféle módon végezhetjük el, parancssoros vagy 
webes felületen keresztül. Jómagam ez utóbbit választottam. 
Példáimban a collab.pelda.com címet fogom használni. 
Töltsük le és bontsuk ki a .tar csomagot a webes könyv- 
tárunkba: 

tf tar -zxvf webcollab-1.62.tar.gz 


Módosítsuk a fő beállító fájlra vonatkozó engedélyeket: 
tf cd Webcollab-1.62/config 
ft chmod 666 config.php 


Böngészőnkben nyissuk meg a collab.pelda.com/WebCollab- 
1.62/setup.php oldalt. Az oldal végigvezet a telepítés ön- 
működő részén, ami magában foglalja egy SOL adatbázis 
létrehozását, a táblákat létrehozó parancsfájl lefuttatását, 
továbbá négy környezeti változó beállítását a megfelelő 
config.php fájlban. 

Állítsuk vissza a fő beállító fájlra vonatkozó engedélyeket: 

ft chmod 664 config.php 
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2. ábra Az új tervezet létrehozását segítő 
űrlapon a hozzáférés-vezérlési és a felhasználók 
értesítésével kapcsolatos beállításokat egyaránt 

megadhatjuk — egyszerűen csak be kell 
jelölnünk a megfelelő négyzeteket 


saként tetszőleges felhasználót kije- 
lölhetünk, ekkor ő kap jogot az adott 
tervezettel vagy feladattal kapcsola- 
tos felügyeleti teendők elvégzésére. 
A csoportok szintén fontos szerepet 
játszanak a feladatok kiosztásában. 

A tulajdonos adott tervezetet egy felhasználóhoz vagy egy 
egész csoporthoz rendelhet hozzá. A tervezeten belüli ten- 
nivalókat később alcsoportok vagy feladatcsoportok alkal- 
mazásával lehet kiosztani. 

A hozzáférés-vezérlés mindenre kiterjedő, kellő rugalmassá- 
got biztosít a rendszergazdáknak és a tervezetek gazdáinak. 
Én például sokszor dolgozom együtt más mérnökökkel, és 
általában mindenkinek jogot kell adnom a feladatok szer- 
kesztésére vagy készre jelölésére, valamint a határidők mó- 
dosítására. Ilyenkor mindenkinek, aki a saját csoportomba 
tartozik, szerkesztési jogot adok a tervezetre. Vannak olyan 
munkáim is, amikor az ügyfeleim csak betekintési engedélyt 
kapnak, nekik csak olvasási jogot szoktam adni. Természete- 
sen azt sem szeretném, ha az ügyfeleim más munkáimba is 
belelátnának. A minden felhasználóra vonatkozó megtekin- 
tési (All users can view this item? jelölőnégyzet) és a felhasz- 
nálócsoportba tartozókra érvényes szerkesztési jog (Anyone 
in the usergroup can edit? jelölőnégyzet) megvonásával 
mindkét problémát könnyedén meg tudom oldani. 


Tervezetek és feladatok létrehozása 

A WebCollab főként kisebb, egy vagy két mondattal leírható 
részfeladatokra bontható tervezetek kezelésére alkalmas. 
Minden tervezetnek van egy leírása, kezdő és záró dátuma, 
fontossága és végrehajtó csoportja. Amikor egy tervezeten 
belül létrehozunk egy feladatot, a program azt egy alter- 
vezetként kezeli, egyébként módosítható adatmezői a szülő- 
munka mezőinek tartalmát veszik át. A programnak ez a ré- 
sze rendkívül hasonló a népszerű tennivalók listája alkalma- 
zásokhoz, ám van annyira rugalmas, hogy nem csupán 
gyorsellenőrző listaként szolgál, de a feladatok mélyebb rész- 
letezését, megjegyzésekkel való ellátását is lehetővé teszi. 

A tervezet és a feladat nézetek azok, ahol a program való- 
ban megmutatja a tudását. Korábban már említettem, hogy 
saját fájlfeltöltő részlege és fóruma van. Itt válik nyilvánva- 
lóvá, hogy a WebCollab csoportmunkát segítő szolgáltatásai 
messze túlmutatnak a hagyományos tennivalók listája al- 
kalmazások tudásán. A felhasználók kérdéseket tehetnek 
fel egymásnak, megjegyzéseket tehetnek, kapcsolódó doku- 
mentumokat tölthetnek fel stb. Ez az, ami a WebCollabet 
megkülönbözteti a feladatkezelő programocskáktól, és ter- 
vezet alapú csoportmunka alkalmazássá nemesíti. A fórum 
révén a dolgok még interaktívabbakká válnak, és talán 

a munkatársak figyelmét is jobban megragadják. 








Nézetek és navigáció 

A nézetek közötti navigálásra könnyű 
ráérezni. Szinte minden elem egy 
hiperhivatkozás, amelyre rákattintva 
az adott információt részletesebben is 
meg tudjuk jeleníteni. Adott tervezet 
fő nézetében például minden feladatot 
a címe képvisel, a címre kattintva az 
adott feladat fő nézetébe jutunk, ahol 
látható a leírása, határideje, a vele kap- 
csolatos fájlok listája stb. 

A tervezet vagy feladat leírásán belül 
megjelenő felhasználó- vagy csoport- 
nevek szintén hivatkozások, ezekre 
kattintva részletesebb adatokat kap- 
hatunk róluk. Alapesetben minden 
rövidített nézetben jelenik meg, bő- 
vebb információkat kattintással érhe- 
tünk el. Bár első látásra ez egy kicsit 
furcsának tűnik, hamar meg lehet 
szokni, és a nézetek közötti váltás 
rutinmozdulattá válik. A navigációt 
a képernyő bal szélén folyamatosan 
látható sáv is segíti. 








3. ábra A feladat nézetek a kapcsolódó 
dokumentumokra vezető hivatkozásokat is 
tartalmaznak. A VPN feladat információs 
oldalának segítségével könnyen megtalálhatjuk 
a szükséges beállító fájlt. 














vemá fiddapató 



































alcsoport szinten is használhas- 
suk. Minden fiókot és jelszót 
MYSOL alatt tárol, a jelszavakat 
természetesen titkosítva. A web- 
kiszolgálót érdemes úgy beállítani, 
hogy az oldalt SSL felett, a 443-as 
kapun keresztül tegye elérhetővé, 
amivel akadályozhatjuk a hozzáfé- 
rések után szaglászó idegenek 
ténykedését. 

Aki az üzletvitel szempontjából 
nélkülözhetetlen adatokat akar 

a WebCollabre bízni, annak javas- 
lom, hogy dolgozzon egy kicsit 

a PHP és a MYySOL közötti kapcso- 
lattartás módszerén, különös tekin- 
tettel az adatbázishoz tartozó fel- 
használónév és jelszó átadásának 
módjára. Összességében ki merem 
jelenteni, elégedett vagyok a fejlesz- 
tők munkájával, amennyiben 

— a célközönséget is figyelembe 
véve - a lehető legmagasabb szintű 
biztonságra törekedtek. 
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Amint a tervezetkezelő csomagoknál 
jellemző, számos különböző nézet 
közül választhatunk, ezek mindegyi- 
ke valamiben eltérő nézőpontot kép- 
visel. A felhasználók bejelentkezés után először a honlap 
(Home Page) nézetet látják. Itt azok a tervezetek és felada- 
tok jelennek meg, amelyekben az illető érintett, valamint 
látható befejezettségi állapotuk és határidejük is. Két továb- 
bi fontos nézet a tennivalók és a naptár nézet; ezek hasz- 
nálata, úgy hiszem, magától értetődő. Ismétlem, a nézetek 
értelmezése a legkevésbé sem bonyolult, ellentétben a ha- 
sonló programok egy részénél megszokottal. Az összes né- 
zetet felhasználó és csoport szerint egyaránt lehet szűrni, 
és mindegyikhez tartozik nyomtatási nézet gomb is, melyre 
kattintva az aktuális tartalmat papírbarátabb formában jele- 





4. ábra A naptár nézet alapszintűnek mondható, 
ám kiválóan szemlélteti, hogy mit mikorra 
kell elvégezni 


Záró gondolatok 

A WebCollab szépsége éppen 
egyszerűségében rejlik. Telepítése 
és fenntartása könnyű. Átfogó és rugalmas eszköz 

a kisebb léptékű tervezetek kezeléséhez. Bizonyára 
vannak, akiket megriaszt az egyszerű felület, ám aki 
csillogó-villogó oldalak helyett pont ilyen gyorsan meg- 
jelenő lapokra vágyik, annak mindenképpen érdemes 
egy próbát tennie vele. Kipróbált megoldásokra épül, 
gyors és stabil, és lévén web alapú, használatához nincs 
szükség külön ügyfélprogramra. A felhasználók hozzá- 
adása és a feladatok, tervezetek létrehozása csupán 
néhány percet igényel. Időszakos használatra is tudom 
ajánlani, ha például bárhonnan elérhető tennivalók lis- 


níthetjük meg. tájára van szükségünk, hiszen egyfelhasználós módban 
is remek segédeszköz. 
Biztonság A nyílt forrású közösség újonnan érkezett tagjaként 


A WebCollab elsősorban kisméretű vagy otthoni iro- 

dai környezetben állja meg helyét. Nem kereskedelmi, 
nyílt forrású fejlesztés, ezért támogatást hozzá gyakorla- 
tilag csak a weboldalon üzemelő fórumon kaphatunk. 
Ez hiába tud hatékony megoldás lenni, az öltönyösök 
az ilyesmit általában nem szeretik. Szerény felhasználói 
bázisát tekintve kétlem, hogy komolyabb támadások 
célpontja lenne, ám az Apache-ra és a MySOL-re már 

ez nem mondható el. Aki nincs bensőséges viszonyban 
az Apache-csal, a PHP-vel és a MySOL-lel, az legalább 
terjesztésének frissítőeszközével ismerkedjen meg, mint 
a Debian apt-getje vagy a SuSE YaST-ja, és próbálja minél 
naprakészebben és minél nagyobb biztonságban tartani 
ezeket a csomagokat. 

A program saját felhasználókezelő és hozzáférés-vezér- 
lési megoldásainak segítségével pontosan szabályoz- 
hatjuk, hogy ki mit lát és mit nem, és a szabályozás 
kellően finom ahhoz, hogy felhasználó, csoport vagy 


a Freshmeat és a SourceForge oldalát böngészve úgy érez- 
tem, mintha szabadúszó művészek filmjeit nézném, vagy 
független rockbandák előadásait hallgatnám. Minden alka- 
lommal, amikor újabb kincsre bukkanunk, úgy érezzük, 
hogy mi vagyunk az elsők, akik felismerték értékeit — én 

is így voltam a WebCollabbel. 
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A cikkhez tartozó források elérhetősége: 
2 www.linuxjournal.com/article/7965 


Mike Cohen az Antropy, Inc., egy kisvállalko- 
zásoknak informatikai tanácsadást végző, 
Dél-Kaliforniában tevékenykedő cég társalapí- 
tója. Szabadidejét a családjával tölti, esetleg 
szörföl egyet a mexikói Todos Santos sziget 
közelében. 
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Optimalizálás a GCC segítségével 


Tekintsük át a GCC O kapcsolóinak jelentését, vizsgáljuk meg, hogy bizonyos 
optimalizálások valójában miért nem azok, aminek gondoljuk őket, valamint 
hogyan választhatunk alkalmazásainkhoz különleges optimalizálási eljárásokat. 


fi rásunkban ismertetjük a GCC fordító eszközlánc által 
] biztosított optimalizálási szinteket, illetve az ezek által 
kínált optimalizálási lehetőségeket. Meghatározzuk, 

hogy mely optimalizálásokat kell explicit módon kiválaszta- 
ni, ide értve a géptípustól függőket is. Vizsgálatunk elsősor- 
ban a GCC 3.2.2-es, 2003 februárjában megjelent változatára 
összpontosít, de megállapításai a jelenlegi, 3.3.2-es változat- 
ra is érvényesek. 


Optimalizálási szintek 

Először nézzük, a GCC milyen kategóriákba sorolja az opti- 
malizálásokat, továbbá a fejlesztő hogyan szabályozhatja, 
hogy mikor melyiket - és sokszor ennél is fontosabb: mikor 
melyiket nem - kívánja használni. A GCC rendkívül sok op- 
timalizálást ismer. Legtöbbjük három szint valamelyikébe 
tartozik, bár bizonyosak több szinten is elérhetők. Vannak 
optimalizálások, melyek az eredményként kapott gépi kód 
méretét csökkentik, mások viszont gyorsabb kódot eredmé- 
nyeznek, akár méretnövekedés árán is. A teljesség kedvéért 
meg kell említeni a nullás szintet is — explicit módon a -Oo 
vagy a -00 kapcsolóval választhatjuk ki —, melyen semmi- 
lyen optimalizálás nem történik. 


Az 1. szint (-01) 

Az első optimalizálási szint célja optimalizált kód gyors 
előállítása. A hangsúly a gyorsaságon van. Az 1. szint két 
további, sok esetben egymásnak ellentmondó céllal is bír, 
ezek a kész kód méretének csökkentése és teljesítményének 
növelése. A -01 szint optimalizálásai túlnyomó részt ezeket 
a célokat szolgálják. Az 1. táblázatban ezek a -01 jelzésű 
oszlopban szerepelnek. Az első optimalizálási szintet 

a következő módon engedélyezhetjük: 

gcc -O1 -o proba proba.c 


Bármely optimalizálást bármely szinten engedélyezhetünk, 
ha a -f kapcsolóval kísérve megadjuk a nevét: 
gcc -fdefer-pop -o proba proba.c 


Megtehetjük azt is, hogy engedélyezzük az első optima- 
lizálási szintet, majd meghatározott elemeit letiltjuk. 
Erre a -fno- előtag szolgál: 

gcc -O1 -fno-defer-pop -o proba proba.c 
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1. táblázat A GCC optimalizálásai és azok a szintek, 
melyeken engedélyezve vannak 















































A fenti paranccsal engedélyezzük az első szintet, majd 
letiltjuk a defer-pop optimalizálást. 


A 2. szint (-02) 

A második szinten minden olyan az adott géptípuson 
támogatott optimalizálás megtörténik, amelynél nem kell 

a sebesség vagy a méret javára dönteni - itt a két szempont 
kiegyensúlyozottsága jellemző. A hurkok kibontására vagy 
a függvények helyi kifejtésére például nem kerül sor - igaz, 
hogy ezekkel a módszerekkel általában növelni lehet a kód 
sebességét, ám alkalmazásukkor maga a kód is hízik. A má- 
sodik szintet a következőképpen engedélyezhetjük: 

gcc -02 -o proba proba.c 


Az 1. táblázat a -02 szint optimalizálásait is tartalmazza. 
A -02 szint a -01 szint összes elemét magába foglalja, illetve 
számos továbbit is tartalmaz. 


A 2.5 szint (-0s) 

Különleges optimalizálási szint (-Os, mint size, vagyis 
méret), esetében minden a kódot nem növelő, második 
szintbeli eljárás engedélyezésre kerül. Ilyenkor a hangsúly 
a méret korlátozására kerül, a sebesség ellenében. Tartalmaz 
minden második szintű optimalizálást, kivéve a határhoz 
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igazítási (alignment) eljárásokat. A határhoz igazítás azt 
jelenti, hogy minden függvényt, hurkot, ugrást és címkét 
olyan címre tolunk el, mely a kettő valamely hatványának 
többszöröse. Az eljárás géptípustól függő. A határokhoz 
igazítással a kód és az adatterek mérete és a futtatás sebes- 
sége egyaránt nő; ez az oka annak, hogy ezek az eljárások 
ezen a szinten letiltásra kerülnek. A méretoptimalizálást 

a következőképpen engedélyezhetjük: 

gcc -os -o proba proba.c 


A gcc 3.2.2-es változata alatt a -Os szinten a reorder-blocks 
engedélyezve van, a 3.3.2-es változatnál viszont le van tiltva. 


A 3. szint (-03) 

A harmadik, és egyben legmagasabb szint újabb optimalizálá- 
sokat tartalmaz (lásd az 1. táblázatot), esetében az elsődleges 
szempont a sebesség növelése, akár méretnövekedés árán is. 
A -02 szint optimalizálásain túl magában foglalja a rename- 
registert is. Az inline-functions (függvények helyi kifej- 
tése) optimalizálást szintén végrehajtja, amivel javul a kód 
teljesítménye, ám nagymértékben nőhet a mérete is, függően 
attól, hogy pontosan milyen függvényeket érint a művelet. 

A harmadik szintet az alábbi módon engedélyezhetjük: 

gcc -03 -o proba proba.c 


Bár a -03 szinten gyorsabb kódot kapunk, a méretnöveke- 
dés kiolthatja a sebességnövekedés kedvező hatásait. 

Ha például a kód mérete meghaladja a rendelkezésre álló 
utasítás-gyorsítótár méretét, akkor számos teljesítménycsök- 
kentő tényezővel kell számolnunk. Lehetséges tehát, hogy 
a -02 szint alkalmazásával jobban járunk, hiszen esetében 
nagyobb a valószínűsége annak, hogy a kód elfér az 
utasítás-gyorsítótárban. 


A géptípus megadása 

Az eddig említett optimalizálások komoly javulást eredmé- 
nyezhetnek az alkalmazás teljesítményében és méretében, 
ám a célgép típusát megadva további előnyökre is számít- 
hatunk. A gép processzorának típusát a gcc -march kapcso- 
lójának segítségével adhatjuk meg. (2. táblázat) 

Az alapértelmezett géptípus az i386. A GCC minden más 
1386/x86 alapú géptípuson is működik, ám az újabb pro- 
cesszorok esetében előfordulhat, hogy gyengébb teljesít- 
ményt kapunk. Ha fontos a kód hordozhatósága, akkor 

a fordítást az alapértelmezett beállítással végezzük. 

Ha inkább a teljesítmény növelését tartjuk szem előtt, 
akkor válasszuk ki a gépünknek megfelelő típust. 

A géptípus kiválasztásának teljesítményre gyakorolt hatását 
egy egyszerű példával szemléltethetjük. Készítsünk egy 
egyszerű próbaprogramot, mely tízezer elemen végez bu- 
borékrendezést. A tömbbe az elemeket fordított sorrendben 
helyezzük el, vagyis a legrosszabb, legtöbb műveletet kívá- 
nó esetet vizsgáljuk. A fordítás menetét és a futtatási időket 
az 1. kódrészlet ismerteti. 

A géptípus megadásával - ez esetben egy 633 MHz-es 
Celeron processzorról volt szó — a fordító képessé válik arra, 
hogy az adott processzortípushoz leginkább illeszkedő uta- 
sításokat állítson elő, illetve egyéb, kifejezetten a géptípusra 
jellemző optimalizálásokat is el tud végezni. Amint az 1. 
kódrészlet is szemlélteti, a géptípus megadásával a futtatási 
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3. táblázat A matematikai egységekkel 
kapcsolatos optimalizálások 





Beállítás Leírás 

387 Szabványos, 387-es lebegőpontos 
társprocesszor 

sse Streaming SIMD Extensions (Pentium III, 
Athlon 4/XP/MP) 

sse2 Streaming SIMD Extensions II (Pentium 4) 


időben 237 ms-os, vagyis 23 százalékos javulást értünk el. 
Fontos megjegyezni, hogy az 1. kódrészletben látható se- 
bességnövekedéshez némi méretnövekedés árán jutottunk. 
A size parancs (2. kódrészlet) segítségével megvizsgálhatjuk 
a kód egyes részeinek méretét. 

A 2. kódrészletből kitűnik az utasításrész (text rész) 28 bájtos 
növekedése. Ebben az esetben viszonylag kis árat fizettünk 
a sebességnövekedésért. 


A matematikai egységgel kapcsolatos optimalizálások 
Léteznek különleges, az i386 és az x86 géptípusra egyedileg 
jellemző optimalizálások, melyeket a programozónak kife- 
jezetten ki kell választania, egyébként nem jutnak érvényre. 
Lehetőség van például matematikai egység választására 

— igaz, sok esetben ez önműködően megtörténik, a meg- 
adott processzor típusa alapján. A -mfpmath- kapcsolóval 

a 3. táblázatban szereplő egységek közül választhatunk. 

Az alapérték a -mfpmath-387. Létezik egy egyelőre kísérleti 
jellegű beállítás is, melynél a program az sse és a 387 egysé- 
get egyaránt megpróbálja kihasználni (-mfpmath-sse , 387). 


Határhoz igazítási optimalizálások 

A második szintnél jó néhány határhoz igazítási optimalizálás- 
ról volt szó. Ott említettem azt is, hogy ezekkel javítani lehet 

a teljesítményen, ám méretnövekedést eredményeznek. Eh- 
hez a géptípushoz további három határhoz igazítási eljárás is 
létezik. A -malign-int segítségével a típusokat 32 bites hatá- 
rokhoz tudjuk igazítani. Ha 16 bites igazítású gépre fordítjuk 
a kódot, a -mmno-align-int eljárást használhatjuk. A -malign- 
double optimalizálás segítségével a double, a long double és 
a long long típusokat tudjuk kétszavas határokra rendezni 
(letiltása a -mmo-align-double paranccsal lehetséges). 

A double típusok határhoz igazításával Pentium gépeken ér- 
hetünk el jobb teljesítményt, természetesen a méret rovására. 
A -mpreferred-stack-boundary beállítással a verem igazí- 
tására is van lehetőség. Esetében a fejlesztőnek a kettő vala- 
mely hatványát kell megadnia a határhoz igazításhoz. Ha 
például a fejlesztő a -mpreferred-stack-boundary-4 érté- 
ket adja meg, akkor a verem 16 bájtos határhoz igazodik 

— ez az alapbeállítás is. Pentium és Pentium Pro processzoro- 
kon a verem double változóit 8 bájtos határhoz érdemes 
igazítani, a Pentium III processzorok viszont 16 bájtos igazí- 
tással teljesítenek jobban. 


Sebességnövelés 
A szabványos függvényeket — mint a memset, a memcpy vagy 
az strlen -— használó alkalmazások esetében a -minline- 
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1. kódrészlet A géptípus megadásának egy egyszerű 
alkalmazás futására gyakorolt hatása 


Imtjacamus]$ gcc -o rendez rendez.c -02 
Imtjacamus]$ time ./rendez 


real Om1.036s5 
user Om1.030s 
sys Om0 . 000s 


Imtjacamus]$ gcc -o rendez rendez.c -02 - 
5 march-pentium2 
Imtjacamus]$ time ./rendez 


real OmO . 7995 
user OmO. 7905 
sys OmO.010s 
Imtjacamus]$ 


2. kódrészlet Az 1. kódrészletben szereplő program 
méretváltozása 


Imtjacamus]$ gcc -o rendez rendez.c -02 
Imtjacamus]$ size rendez 
text data bss dec hex filename 
842 252 4 1098 44a rendez 
Imtjacamus]$ gcc -o rendez rendez.c -02 
5 -march-pentium2 
Imtjacamus]$ size rendez 


text data bss dec hex filename 
870 252 4 A 26 466 rendez 
Imtjacamus]$ 


al1-stringops beállítással, a karakterlánc-műveletek helyi 
kifejtésével tudjuk növelni a teljesítményt. Természetesen 
mellékhatásként itt is számolnunk kell a kód méretének 
növekedésével. 

A hurkok kibontása úgy történik, hogy a fordító egy-egy 
ciklusban a lehető legtöbb munkát végezteti el a program- 
mal, így kevesebb ismétlésre van szükség. Ez esetben a tel- 
jesítmény javulása és a méret növekedése ismét együtt jár. 
A hurkok kibontását a -funrol1-1oops beállítással engedé- 
lyezhetjük. Azokban az esetekben, amikor az ismétlések 
számát nehéz meghatározni, márpedig ez a -funrol1- 
1oops használatának előfeltétele, a -funrol1-a11-1oops 
optimalizálással lehet az összes hurkot kibontani. 

Hasznos eljárás a -momit-leaf-frame-pointer, ám használa- 
ta megnehezíti a kód hibáinak felderítését. Segítségével a keret 
mutatót (frame pointer) egy regiszteren kívül tarthatjuk, így 
kevesebbszer kell megadni és törölni az értékét. Mindemellett 
a regiszter elérhetővé válik a kód számára is. A -fomit-frame- 
pointer optimalizálás szintén jó szolgálatot tehet. 

A -03 szinten, illetve a -finline-functions beállítás hasz- 
nálatakor egy különleges átadott érték felületen keresztül 
megszabhatjuk, hogy legfeljebb mekkora függvényeket aka- 
runk helyileg kifejteni. Az alábbi parancsban például a helyi 
kifejtésű függvények méretét 40 utasításban korlátozzuk: 
gcc -o rendez rendez.c -—param max-inline-insns-40 








3. kódrészlet: Egyszerű példa a gprof használatára 


Imtjacamus]$ gcc -o rendez rendez.c -pg -02 
5 -march-pentium2 

Imtjacamus]$ ./rendez 

Imtjacamus]$ gprof -no-graph -b ./rendez 

5 gmon.out 

Flat profile: 

Each sample counts as 0.01 seconds. 


27 — cumulative — self self total 
time — seconds — seconds cajliis Simszeatluimszíeadh 
100.00 0.79 (019 74) it 790.00 790.00 

0.00 0879 0.00 al, 0.00 0.00 
Imtjacamus]$ 


Ezzel a módszerrel kézben tarthatjuk a -finline- 
functions alkalmazása kapcsán jelentkező kódméret- 
növekedést. 


A kód méretének optimalizálása 

A verem alapértelmezett határhoz igazítási értéke 4 vagy 16 
szó. Helyszűkével küszködő rendszereknél az alapértéket 
a -mpreferred-stack-boundary7-2 beállítással nyolc bájtra 
is állíthatjuk. Állandók, például karakterláncok vagy lebe- 
gőpontos értékek megadásakor ezek a független értékek 
általában saját helyet foglalnak el a memóriában. Jobb, ha 
nem engedjük szabadjára őket, ugyanis az azonos jellegű 


állandók összefogásával csökkenthet- 
jük a tárolásukhoz szükséges hely mé- 
retét. Ezt a különleges optimalizálást 
a -fmerge-constants beállítással 
vehetjük igénybe. 


Optimalizálás grafikus hardver- 
elemekre 

A megadott célgép típusától függően 
számos további kiterjesztés kerül en- 
gedélyezésre. Ezeket explicit módon 


name is lehet engedélyezni vagy tiltani. 
bubblesSort A -mmmx és a -m3dnow például önműkö- 
jnútetlksie dően engedélyezésre kerül, amennyi- 


ben a megadott processzortípus támo- 
gatja az adott utasításkészletet. 


További lehetőségek 

Számos a sebesség növelésére és a kódméret csökkentésére 
alkalmas optimalizálásról és kapcsolóról ejtettünk szót, 
most említsünk meg néhány mellékes, ám sokszor roppant 
hasznos lehetőséget. 

A -ffast-math optimalizálás olyan átalakításokat végez, 
melyek nagy valószínűséggel helyes kódot eredményeznek 
ugyan, ám nem biztos, hogy szigorúan igazodik az IEEE 
szabvány előírásaihoz. Bátran használhatjuk, ám gondosan 
teszteljük le az eredményt. 

Ha a globális közös alkifejezések kiküszöbölése enge- 
délyezve van (-fgcse, -02 vagy magasabb szint), akkor 
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további két lehetőség nyílik a betöltésifelmentési művele- 
tek számának csökkentésére. A -fgcse-1]m és a -fgcse-sm 
optimalizálás a betöltő és elmentő műveletek hurkon kí- 
vülre helyezésével alkalmas a hurkon belül végrehajtott 
utasítások számának csökkentésére, amivel nő a hurok 
lefuttatásának sebessége. A -fgcse-1m (10ad-motion, 
betöltő műveletek) és a -fgcse-sm (elmentő műveletek) 
kapcsolókat együtt kell használni. 

A -fforce-addr optimalizálás arra kényszeríti a fordító- 
programot, hogy a címeket regiszterekbe mozgassa át, mie- 
lőtt bármilyen aritmetikai műveletet végrehajtana rajtuk. 
Hasonló a -fforce-mem beállításhoz, mely a -02, a -os és 

a -03 szinten alapesetben engedélyezve van. 

A mellékoptimalizálások közül utolsóként a -fsched- 
spec-loadot említeném meg, mely a -fschedule-insns 
optimalizálással együtt használható. A -02 szinttől kezdve 
alapesetben is engedélyezve van. Segítségével mód nyílik 
bizonyos betöltő utasítások elméletileg hatékonyabb végre- 
hajtást eredményező áthelyezésére, amivel a lehető legki- 
sebbre csökkenthető az adatfüggőségek miatt a futtatásban 
bekövetkező fennakadások száma. 


A kapott javítások kipróbálása 

A korábbiakban a time paranccsal vizsgáltuk meg az adott 
utasítások végrehajtására fordított időt. Az alkalmazások pro- 
filozásakor természetesen ennél jóval részletesebb betekintést 
kell nyernünk a kód működésébe. A GNU gprof segédprog- 
ram és a GCC fordító együttesen képesek megfelelni az ilyen 
jellegű igényeknek is. A gprof tárgyalása túlmutatna jelenlegi 
témánkon, ám a 3. kódrészlet jól példázza a használatát. 

A kódot a -pg kapcsolóval fordítjuk le, így belekerülnek 

a profilozáshoz szükséges utasítások. A kód lefuttatása után 
az eredmények a gmon . out fájlba kerülnek, ebből a gprof 
segédprogrammal állíthatjuk elő az emberi szem számára is 
olvasható profilozási adatokat. A gprof futtatásakor ebben az 
esetben a -b és a -no-graph kapcsolókat használtam. Ha tö- 
mör kimenetet szeretnénk (vagyis el kívánjuk hagyni a me- 
zők bővebb magyarázatait), a -b kapcsolót kell használnunk. 
A -no-graph kapcsoló letiltja a függvényhívási grafikon meg- 
jelenítését; ez egyébként az egyes függvények közötti hívá- 
sokat és a függvények futtatásának idejét szemlélteti. 

A harmadik kódrészletre tekintve megállapíthatjuk, hogy 

a bubblesort, vagyis a buborékrendezést végző eljárás egy- 
szer került meghívásra, és futtatásának ideje 790 ms volt. 
Az init list függvényt szintén meghívtuk, ennek futtatá- 
sa kevesebb mint 10 ms-ot igényelt (ez a profilozási minta- 
vétel felbontása), ezért mellette nullás érték szerepel. 

Ha a sebesség helyett inkább a méretváltozások érdekelnek 
bennünket, akkor a size parancsot kell használnunk. Még 
részletesebb adatokhoz az objdump segédprogrammal jut- 
hatunk. Például a kódban lévő függvények listáját a . text 
részekre keresve állíthatjuk elő: 

objdump -x rendez ] grep .text 


A kapott listából ezután ki tudjuk választani ak komolyabb 
érdeklődésünkre is számot tartó függvényt. 


Az optimalizálások vizsgálata 
A GCC optimalizáló lényegében egy fekete doboz. 
Megadjuk neki a beállításokat és a megfelelő kapcsolókat, 
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majd kapunk egy kódot, ami vagy jobb, vagy rosszabb. 
Ha javulást látunk, vajon mi történt pontosan? Erre 

a kérdésre a kód vizsgálatával kaphatunk választ. 

A célutasítások kiírására a -S kapcsolóval vehetjük rá 

a fordítót: 

gcc -c -S proba.c 


Ekkor a gcc előfordítja a kódot (-c, mint compile), illetve 
megjeleníti a forrás assembly kódját (-S). A kapott assembly 
kimenet a proba. s fájlba kerül. 

Az előző megközelítés hátránya, hogy csak assembly 

kódot látunk, a tényleges utasítások méretéről semmit 

nem tudunk meg. Ha ez a célunk, akkor az objdump-pal az 
assembly mellett natív utasításokat is elő tudunk állítani: 
gcc -c -g proba.c 

objdump -d proba.o 


Az előfordítást a -c kapcsolóval kértük a gcc-től, a hiba- 
keresési adatokat pedig a -g kapcsolóval illesztettük be. 
Az objdump a -d kapcsoló hatására szedi szét az objektum- 
kódban szereplő utasításokat. Végül az assemblyvel meg- 
szórt forrást az alábbi paranccsal kapjuk meg: 

gcc -c -g -Wa,-ah1],-L proba.c 


A parancs futásakor a GNU assembler állítja elő a kód- 
forrást. A -wa kapcsolóval a -ah1 és a -L kapcsolót adjuk 
tovább az assemblernek, amely így a szabványos kimenet- 
re magas szintű kódból és assemblyből felépülő tartalmat 

ír ki. A -L kapcsoló a szimbólumtábla helyi szimbólumainak 
megtartását szolgálja. 


Osszefoglalás 

Mivel minden alkalmazás más, nem adható olyan bűvös 
beállításegyüttes, amellyel minden esetben a legjobb 
eredményt lehetne elérni. Megfelelő teljesítményt a leg- 
egyszerűbben a -02 optimalizálási szint használatával 
kaphatunk. Ha a hordozhatóság nem szempont, akkor 

a -march- kapcsolóval adjuk meg a célprocesszor típusát. 
Ha tárhely tekintetében szűkösen állunk, akkor elsőként 
a -Os szinttel próbálkozzunk. Ha a lehető legnagyobb tel- 
jesítményt akarjuk kipréselni a kódból, akkor több szinttel 
is próbálkozzunk meg, a kapott kódot pedig vizsgáljuk 
meg az említett segédprogramokkal. Adott optimalizálá- 
sok engedélyezésével vagy letiltásával szintén van esé- 
lyünk arra, hogy a lehető legjobb teljesítményt hozzuk 

ki a fordítóból. 
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A cikkhez tartozó források elérhetősége: 
5 www.linuxjournal.com/article/7971 


M. Tim Jones (mtjeEmtjones.com) 

A longmonti, Colorado állambéli Emulex Corp. vezető 
főmérnöke. Belsőprogram-tervező mérnök, emellett 
nemrég készült el BSD Sockets Programming from 

a Multilanguage Perspective című könyvével. Korábban 
kommunikációs és tudományos műholdakhoz írt rend- 
szermagokat, jelenleg hálózati készülékekhez fejleszt 
belső programokat. 








Bemutatkozik az Ardour 


A Linux rögzítőstúdiónk szíve a merevlemezes rögzítő. Vegyük szemügyre hát 
az Ardour-t, amely profi szintű rögzítési módszereket hoz a nyílt forrás világába. 


kortárs zenészek számítógépeiket digitális audio 
A munkaállomásként (DAW) rengeteg, hanggal kap- 

csolatos műveletre használják. A leggyakoribb mű- 
veletek a rögzítés, hangállomány szerkesztés, hatások hoz- 
zákeverése, dinamikus feldolgozás illetve az audio számok 
felkészítése a CD mester lemezre íráshoz. 
A modern zenészek számítógép alapú stúdiójában központi 
szerepet játszik a merevlemezes rögzítő (HDR). Az Apple 
vagy Microsoft Windows gépeken dolgozók jó néhány HDR 
rendszer között válogathatnak, Linux alatt azonban, egé- 
szen a közelmúltig nem volt egyetlen igazán professzionális 
rendszer sem. Professzionális minőségű HDR készítése nem 
éppen egyszerű feladat és az üzleti HDR fejlesztők nem túl 
sok technikai segítséget nyújtottak az önjelölt nyílt forrás- 
kódú DAW fejlesztőknek. 
Manapság azonban, Paul Davis vezető tervező/programo- 
zónak és tehetséges csapatának hála, a linuxos zenészek 
rendelkezésére áll a őshonos fejlesztésű és professzionális 
színvonalú Ardour HDR/DAW. 


Mire jó, és mire nem 

Az Ardour magas minőségű hanganyagokhoz szánt, többsá- 
vos rögzítő és szerkesztő rendszer. Az Ardour támogatja az 
audio feldolgozó bővítményeket (LADSPA és VST) valamint 
automatizált paraméter vezérléssel, kifinomult csúsztatás 
(panning) vezérléssel és sok fejlett szerkesztési funkcióval 
rendelkezik. Ismeri a MIDI időkódot (MTOC), a MIDI 
SMPTE kódolási átlag időkódot, a MIDI gépi vezérlést 
(MMO) azaz a MIDI külső keverők és rögzítők vezérléséhez 
szánt üzenetkészletét, illetve a JACK-et, azaz a Linux és 
Mac OS X alatt használt alacsony lappangási idejű kiszolgá- 
ló és alkalmazás átvitelvezérlés felületet. 

Adattípusokat is támogató professzionális hangrögzítési al- 
katrészeket ritkán találunk a fogyasztói szintű rendszerek- 
ben. Egy profi DAW nagyobb bitmélységben képes kezelni 
a hangot, a mélyebb amplitúdó tartomány és a nagyobb 
pontosság érdekében; magasabb mintavételezést alkalmaz, 
a pontosabb frekvencia felbontás miatt; és nagyobb rugal- 
massággal rendelkezik a hang- és térkezelés területén. 
Egyáltalán nem ritka, hogy a profi rögzítők 32-bites, J9ő$kHz 
mintavételezéssel rögzített hangfájlokkal dolgozzanak, 

ami több mint kétszerese a kompaktlemezek felbontásának. 
Az Ardour nem MIDI állomány rögzítő vagy szerkesztő. Sem- 
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1. ábra Az Ardour többsávos rögzítő és szerkesztő rendszer amely 
egyaránt támogatja a fogyasztói és professzionális alkatrészeket 


mit nem tud a hangjegyekről, és nem is hangállomány-szer- 
kesztőnek szánták. Az Ardour csak néhány beépített jelfeldol- 
gozó képességgel rendelkezik, további feldolgozási képessé- 
geit bővítményekből meríti. Végül, közvetlenül nem nyújt 
lehetőséget CD-készítésre és írásra, viszont úgy írták meg, 
hogy jól együttműködjön a kiváló JAMin tervezőkészlettel. 


Alkatrészigény 

Az Ardouwr használhatóságát nagyban befolyásolja a rendel- 
kezésünkre álló alkatrészek képességei. Amennyiben a hang- 
kártyánkat és hangeszközünket támogatja az ALSA hang- 
rendszer, valószínűleg működni fog az Ardour-ral is; ugyan- 
akkor a szokványos fogyasztói cikkek nem igazán alkalma- 
sak az Ardour képességeinek teljes kihasználására. Nagysze- 
rű dolgokat lehet csinálni az Ardour és egy SoundBlaster Live 
párossal is, de profi munka esetében az Ardour jobban örül 
egy többcsatornás digitális audio csatolófelületnek, legyen 

az RME Hammerfall vagy éppen M-Audio Delta kártya. 

Az auido felületünk megvásárlása előtt érdemes előtanul- 
mányokat végezni. Nézzük meg az ALSA oldalán megjele- 
nő támogatott alkatrészeket és próbáljunk meg keresni 
valakit aki megjegyzéseket fűzött a választott kártyánkhoz. 
Az Ardour képes válaszolni a MIDI paraméter-vezérlésre, 
így a MIDI megvalósítás lapot is érdemes áttanulmányozni 
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azokhoz a külső eszközökhöz amelyekkel használni szeret- 
nénk. Nézzük meg, a keverőnk adatai között szerepel-e 

az MMC vagy MIC trendszer. Az Ardour képes használni 
az automatikus keverővezérlést, de akár csak az előbb, 

az alkatrésznek is alkalmasnak kell lennie ilyesmire. 

Az Ardowr felhasználói levelezőlistán gyakran felmerül az 
elégséges felhasználói rendszer kérdése. Kielégítő eredmé- 
nyekről számoltak be 500 Mhz-es processzorral is, de egy 
ilyen rendszer professzionális felhasználáshoz már biztosan 
nem elegendő. A gyors processzor pontos szinkronizálást 
biztosít, miközben több sávot rögzítünk vagy játszunk le, és 
néhány hatás használatához pedig feltétlenül szükséges egy 
kis sebesség. Például egy jó visszhang hatás igencsak CPU- 
igényes művelet. Ezen kívül egy nagy és gyors merevlemezre 
is szükségünk lesz, melyet a hdparm eszközzel optimális mű- 
ködésre bírtunk. Többsávos, áramló adatok szinkronizálásá- 
hoz viszont feltétlenül gyors CPU és lemez szükséges. A 32- 
bites digitális hangállományok elég nagyok lehetnek és a egy 
szokásos rögzítési folyamat előre nem látható lemezmennyi- 
séget igényelhet. Profi felhasználáshoz érdemes két lemezzel 
felszerelni a gépünket. Az egyik lemezt a rendszernek és al- 
kalmazásoknak tartjuk fönn, a másikat pedig kizárólag hang- 
adatok rögzítésére használjuk. Az Ardour weblapján különfé- 
le ajánlott CPU és merevlemez paramétereket találunk, sőt 
még javasolt alaplapokat is. Ha a legjobb eredményt szeret- 
nénk elérni az Ardour-al, kövessük a tervezők tanácsait. 
Aaron Trumm kiváló cikke, a ,The Linux-Based Recording 
Studio" foglalkozik a komoly rögzítési feladatokhoz hasz- 
nálható külső felszerelések beállítási kérdéseivel. Ahelyett, 
hogy itt elismételném Aaron javaslatait, olvasóinkat inkább 
arra bíztatnám, hogy e cikkben nézzenek utána a mikrofo- 
nok, keverők, monitorok, hangfalak és egyéb külső felszere- 
lésekkel kapcsolatos kérdéseknek. 


A program igényei 

Az Ardoxwr jelenlegi nyílt változatát forráskódként tölthetjük 
le. Néhány Linux terjesztéshez (Red Hat/Fedora, Mandrake, 
Debian és Slackware) csomagok is rendelkezésre állnak. 

A hálózati források között megtaláljuk őket. A CVS elérés je- 
lenleg nem nyilvános, de az Ardour weblapján mindig meg- 
találjuk az aznap esti tarlabdát. Az Ardour forrásból történő 
fordítása nem különösebben bonyolult, és az összes szüksé- 
ges információt megtaláljuk a tarlabdában. 

Az Ardour weblapján utánanézhetünk a program fordításá- 
hoz és telepítéséhez szükséges legfrissebb támogató eszkö- 
zöknek. Az Ardour működéséhez szükséges csomagok: az 
ALSA rendszermag hangrendszer, a JACK audio-kiszolgáló, 
a LADSPA bővítmény API és gyűjtemény valamint különféle 
audio-vonatkozású programelemek. Meglévő Linux telepíté- 
sünket is beállíthatjuk úgy, hogy optimális teljesítménnyel 
fusson a program, de ha komolyan szeretnénk az Ardourral 
foglalkozni, érdemes audio-optimalizált rendszert választani. 
Ilyenek például a Debian alapú AGNULA/Demudi, vagy 

a Planet CCRMA, Red Hat/Fedora csomagok. A Slackware fel- 
használók Luke Yelavich AudioSlack csomagjait telepíthetik, 
a Mandrake felhasználók pedig valamennyi szükséges cso- 
magot megtalálják Thac lapján. 

Az autófeldolgozást segítő JAMin eszközkészlet feladata 

a mesterlemezre írandó sávok előkészítése. A mesterkészítő 
folyamatban használt főbb eszközök a tömörítők, ekvalize- 
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2. ábra Átméretezett sávok, területszerkesztő 
és az LADSPA bővítmény 


rek és határolók (limiters) amelyek a sávok közötti amplitú- 
dó és a frekvencia egyenlőtlenségeket csökkentik. Ha egy 
teljes CD lemezt szeretnénk rögzíteni az Ardourral, érde- 
mes a JAMinnel készíteni a mestert. 


Főbb képességek 

Minden modern HDR a három általános digitális hang 
munkafolyamatnak megfelelően három alapvető feladatot 
lát el, azaz: rögzítés, szerkesztés és keverés. Valamennyi fá- 
zis önmagában is elég összetett feladat, az Ardour praktikus 
felhasználói felülete mégis könnyen kezelhetővé teszi 

a bonyolult programot. 

Az Ardouwr a rendelkezésre álló alkatrész korlátokig dolgo- 
zik. Ha 32-csatornás [/O hangfelülettel rendelkezünk és ta- 
lálható hozzá ALSA meghajtó egyszerre 32 hangcsatornával 
dolgozhatunk. A csatornák sávokhoz rendelése nagyon ru- 
galmas, és minden sáv monó illetve sztereó bemenet keze- 
lésére is alkalmas. Az Ardour szinkronizálási felülete jelen- 
leg legjobban a JACK-rendszerű alkalmazásokkal működik, 
így például a Hydrogen dobgéppel vagy a Rosegarden 
audio/MIDI szekvenszerrel. Rengeteg munkát fektetnek 
ugyanakkor a MIDI időkód fejlesztésbe is. 

Mint korában említettük, az Ardour nem hangfájl szerkesztő, 
de azért tartalmaz néhány többsávos rögzítésre kihegyezett 
szerkesztési műveletet. Ilyen például az általános, és a nem- 
isannyira-általános kivágás/másolás/beillesztés műveletek, 
csoportosított sávszerkesztés illetve a sáv és szegmensáthelye- 
zések részletes vezérlése. Az Ardour maga is képes időnyúj- 
tási és amplitúdó normalizálási feladatok elvégzésére, ám 

a feldolgozás oroszlánrészét az LADSPA bővítmény végzi. 


Az LADSPA 

A Linux Audio Developers Simple Plugin Architecture 
(LAPSDA) lényegében egy könnyen használható programo- 
zói felület, melynek segítségével hatásokat és más bővítmé- 
nyeket építhetünk a linuxos audio alkalmazásainkba. 

Az API-t annyira széles körben használják a Linux audio 
fejlesztők, hogy a felhasználók ma már elvárják, hogy egy új 
hangkezelő vagy zeneprogram ismerje a LADSPA rendszert. 
Az Ardowr adatsávokon, területeken (regions), tartományo- 
kon (ranges) , darabokon (chunks) és csoportokon képes dol- 











3. ábra A Mixer panel sávcsíkját úgy kell elképzelnünk, mintha 
a hangadat felülről lefelé mozogna minden egyes sávban 


gozni. Az adatmegjelenítés változtatható: nagyíthatjuk 
vagy kicsinyíthetjük a sáv megjelenítését, a csoportosítás 
segítségével pedig csak az adott szerkesztési csoportba tar- 
tozó sávokat látjuk. A 2. ábrán megfigyelhetjük az Ardour 
sávmegjelenítőjének átméretezési képességét, a területszer- 


kesztőt és az erősítés (gain) automatizáló görbét. 


Hány sávot használjunk? 

Minthogy általában felvételkészítők használják, a sáv kifeje- 
zés pontosan megfelel a mágneses szalagra rögzíthető hang 
fogalmának. A digitális hangot más módszerrel rögzítjük 

a merevlemezen, ám a régi kifejezés továbbra is megma- 
radt, hiszen több audiofolyamot grafikusan folyamatos sáv- 
ként jelenítünk meg. A csatorna fogalmát ugyanakkor talán 
a keverő működésén keresztül lehet legjobban megérteni. 
A többcsatornás keverők több bemenetet (csatornát) kezel- 
nek, amelyek jeleit szabadon összevegyíthetik és átirányít- 
hatják, mielőtt azok a keverő kimenetére kerülnénk. Ehhez 
hasonlóan a többcsatornás digitális hangfelület is több ve- 
gyíthető és átirányítható csatornát kezel a HDR sávjainkon. 
A csatornák számát a csatolt eszköz határozza meg. 

Mint korábban említettük, a fogyasztói termékek ritkán képe- 
sek sztereó ki/bemenetnél többre, míg a professzionális felsze- 
relések akár 50 vagy több csatornát is kezelhetnek. A lemez- 
hely gyorsan fogy a felvételeink különféle változatai, ideigle- 
nes sávjai és biztonsági másolatai tárolása során. A program 
korlátozhatja az használható sávok számát, de az egyszerre 
rögzíthető sávok számát a merevlemez sebessége határozza 
meg. Ne feledjük, a magas minőségű digitális hang igen 
keményen igénybe veszi a rendszererőforrásainkat. 

Az Ardour keverőpanelje sávonként egy-egy csúszkából és 
mester vezérlőcsíkból áll. A sávcsík a , felülről lefelé" adatlo- 
gikának megfelelő szakaszokból áll. A csík tetején kezdődik 
a bemenet, ez után következnek a vezérlők (jelpolaritás, 
szóló és néma sáv állapot), aztán keresztülhalad a előkioltás 
(pre-fader) bővítményen, magán a sáv kioltás (fader) szaka- 
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szon, majd a utókioltás (post-fader) bővítményeken, végül 
eléri végleges állapotát ahonnan a kimenetre vagy kimene- 
tekre kerülhet. A kimenet általában, de nem feltétlenül 

a mester buszt jelenti. Az Ardour keverőjének további 
figyelemre méltó képességei: automatikus erőszabályzás, 
automatikus rögzítési és visszajátszási kioltás mozgatás; 
keverőkbe és vissza irányuló MIDI-vezérlés a MIDI-gép- 
vezérlésen keresztül; valamint az automatikus bővítmény- 
paraméter kezelés. 

Mivel az Ardour Erik de Castro Lopo sndfile könyvtárát 
használja, a hangadatokat (sáv, terület és munkafolyamat 
(session)) a libsndfile által ismert bármelyik formátumban 
exportálhatjuk és importálhatjuk. Jelenleg körülbelül 20 
különféle audio fájlformátumot használhatunk, beleértve 
a legnépszerűbb fogyasztói és profi formátumokat is. 


Az Ardour munkafolyamatai 

A következő munkafolyamat leírásával az Ardour mint 
többsávos rögzítő rendszer képességeit szeretném bemutat- 
ni. Megpróbáltam kerülni a bonyolult műszaki kifejezése- 
ket, de a cikket nem bevezetőnek szántam a digitális rögzí- 
tés világába. A témával kapcsolatos alapinformációkat meg- 
találjuk a www.homerecording.com lapon, illetve komolyabb 
szinten a www.prorec.com oldalon. Sok egyéb hálózati és 
nyomtatott forrást találhatunk a Google és Amazon megfele- 
lően formázott kereséseivel. 

A felhasznált alkatrészek: M-Audio Delta 66 digital audio 
felület. Ez a rendszer PCI kártyával és breakout dobozzal 
rendelkezik, amely összesen 4Xx4 analóg [/O és 2x2 digitális 
I/O csatornát biztosít. A digitális kapukat egyaránt állíthat- 
juk S/PDIF azaz magas színvonalú fogyasztói szintű digitá- 
lis I/O jelre, vagy rögzítési iparban használt AES/EBU szab- 
ványra. Minden bemenet sztereó kapu, így lényegében 
összesen 12 bemeneti csatornánk van, ami lényegesen ru- 
galmasabb kombinációkat tesz lehetővé mint egy szokásos 
fogyasztói egyszerű sztereó hangkártya. 

A munkafolyamatban két külső keverőt használtam. 

A külső szintetizátorokhoz Yamaha DMP11 alkalmaztam, 

a vokál, gitár és harmonika előadásokat pedig egy Tascam 
TM-D1000 vezérelte mielőtt a Delta 66-ra kerültek volna. 

A Tascam keverő S/PDIF digitális kimenettel rendelkezik, 
ezért a Delta kártya digitális bemenetére tudtam kapcsolni. 
Az volt a tervem, hogy az Ardour segítségével több hang- 
szer és vokál sávon rögzítem az eredeti dalt, majd keverés- 
sel újra előállítom a kis csapat élő zenéjének hangzását. 
Persze ebben a munkafolyamatban a kis csoport egyedül 
én voltam, kiegészítve néhány importált WAV állománnyal 
és egy kis Ardourbeli többsávosítással. Szerettem volna né- 
hány LADSPA bővítményt is használni, hogy hatásokkal 
tűzdeljek meg bizonyos sávokat, valamint ki akartam hasz- 
nálni az Ardour csúsztatás (pan) vezérlőjét amellyel beállít- 
hatom a sávok pontos helyzetét a sztereó audio térben, 
ahogy a zenészeket állíthatnánk a színpadon. 

A zongora, basszus, gitár és dob részekhez MIDI szekven- 
szert használtam. Minden részt MIDI állományként mentet- 
tem el, majd mindegyiket WAV audio állománnyá alakítottam 
a népszerű TiMidity MIDI eszközzel. A dobsávot sztereó sáv- 
vá, a többit pedig monaural állománnyá alakítottam, továbbá 
minden fájl 16-bites 44.1kHz WAV formátumban készült. 
Ezek után valamennyi készen állt a Ardourba olvasásra. 
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4. ábra A Delta 66 I/O csatornái a gjackctl megjelenítésében 


Amikor először megnyitjuk az Ardourt, egy üres sávmegje- 
lenítőt láthatunk, illetve egy udvarias figyelmeztetést, mi- 
szerint létre kell hoznunk egy Ardour munkafolyamatot 

a Session/New dialógusban. Munkafolyamat sablonokból is 
válogathatunk, mivel azonban én tudtam a pontos sávigé- 
nyeimet inkább saját sávkiosztást hoztam létre egy sztereó 
és négy monó sávhoz. A WAV állományokat a sávokba im- 
portáltam és már meg is volt a kísérő együttesem. 
Következő lépésként további három sávot rögzítettem az 
Ardourban, felvéve a ritmusgitár részt, a vokál sávot és 

a harmonika szólót. Ardour alatt a rögzítés nagyon egysze- 
rű: kattintsunk a kiválasztott sáv R gombjára (ezzel élesítjük 
felvételre), majd állítsuk be a bemeneteket és a szinteket 

a sáv keverőcsíkjában. Ezt követően kattintsunk a főablak 
nagy vörös Record gombjára, bökjünk a transport play 
vezérlőre és máris rögzíthetjük amit szeretnénk. Egy vagy 
több további sávot is figyelemmel kísérhetünk, és valós idő- 
ben szóló módba kapcsolva vagy elnémítva a sávokat vagy 
sávcsoportokat különféle együtteseket tesztelhetünk. 
Amikor elégedett voltam a rögzített előadással, elkezdtem 
dolgozni a keverésen. A nyers keverékben több dologra is 
oda kellett figyelni: a ritmusgitár sávnak hangerőkioltást 
(volume fade-out) kell adni a kiegyenlítési (EO) átvitel so- 
rán, a MIDI hangszerek nem voltak elég élesek a keverék- 
ben valamint minden normalizálni és egyensúlyozni 
kellett. Szerencsére az Ardour mindezt igen egyszerűen 
kezelte. A kiegyenlítéshez és hangosításhoz az LADSPA 
bővítményeket, illetve szükség esetén az Ardour saját 
belső normalizálási rutinját használtam. A vokál és har- 
monika részeknél alkalmazott visszhang hatás szintén 

a LADSPA bővítmény érdeme. 

A ritmusgitár sávom kioltása (fade-out) érdekes feladatnak 
bizonyult. Először is a sáv automatizálási gombjára kattint- 
va beállítottam az automatizálási görbét, majd az egérrel 
és a Gain mode gomb segítségével meg tudtam rajzolni az 
amplitúdó görbét. Később felfedeztem, hogy az Ardour 
vezérlés automatizálását a keverőben is használhatom. Az 
a kioltandó munkarészt és csökkentettem a kioltó szintjét. 
Miután az Ardour rögzítette a kioltó változását, az automa- 
szás közben magától lefelé mozdult. Ráadásul a kioltókat 
szimulációs műveletek (így az együttes automatizálási gör- 
bekészítés) esetén is összekapcsolhatjuk keverőcsoportokká. 


Normalizálás és kiegyenlítés 
A normalizálás során a jel legnagyobb amplitúdóját a ma- 
ximumra növeljük vágás előtt. Az összes többi amplitúdó 
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az új csúcsamplitúdó arányában változik. A kiegyenlítés 
(egualization) egy adott frekvencia vagy frekvenciatarto- 
mány erejét növeli vagy csökkenti. Az autók sztereó 
hangrendszeréből ismert, úgynevezett polcos (shelving) 
grafikus kiegyenlítő (ekvalizer) jó példa az ilyen EO esz- 
közre. Ezek az eszközök a hallható skálát többé kevés- 
bé vékony részekre osztják, ahol valamennyi részben 
lehetőségünk van erősíteni vagy gyengíteni az adott 
frekvencia tartományt. 

Hogyan végződött ez a kis kreatív kísérlet? Mindenki 
saját fülével győződhet meg róla; az URL-t a források 
között találjuk. 

Ne feledjük, hogy a felvétel még nincs kiírva, és még 
visszatérhetek az eredeti munkámhoz és módosításokat 
végezhetek rajta. Szívesen látok minden javaslatot, de azért 
legyünk elnézőek szerény próbálkozásomhoz. 


Szinkronizálás 

A JACK alacsony lappangású audio kiszolgáló és átvitel 
vezérlő csatolófelület szintén Paul Davis szerzeménye, 

így bizton számíthatunk rá, hogy az Ardour JACK szinkro- 
nizálási képességei elég fejlettek. A Hydrogen dobgépet és 

a Rosegarden szekvencetrt tesztelve a mester és szolga JACK 
módokban vegyes sikereket értem el. Mindkét program 
gond nélkül szinkronizált az Ardourral oda-vissza JACK-en 
keresztül. A Hydrogen kiválóan működött ám a Rosegarden 
szoftszintetizátor kimenetének rögzítésével gondjaim vol- 
tak. A Rosegarden csapat ismeri a problémát és tervezik 

a javítását, így a Rosegarden weblapján érdemes utánanézni 
a legfrissebb híreket. 

A tesztelés idején az Ardour MTC küldés/fogadás része ép- 
pen komoly újraírás alatt állt, így nem tudtam igazán hasz- 
nálható teszteket készíteni. Ugyanakkor az MTC támogatás 
egy jelentősebb elem, ami sok Ardour felhasználó kívánság- 
listáján megtalálható, így a ftéennmaradó hibák minden bi- 
zonnyal javítva lesznek még az 1.0 megjelenése előtt. Az 
Ardour jövendőbeli verzióiban valószínűleg egyéb szinkro- 
nizálási lehetőségek is helyet kapnak majd. Várólistán talál- 
juk a SMPTE olvasást, MIDI órát és SPP-t (song position 
pointer, azaz számpozíció mutató) mint lehetséges jelölteket, 
de ezekkel a protokollokkal már csak az Ardour 1.0-ás ver- 
zió megjelenését követően fogunk tudni dolgozni. 


Benyomások 

Minél többet tudok meg az Ardourról, úgy tűnik annál töb- 
bet kell még tanulnom. Az Ardour tervezőinek hála a mun- 
kafelület tiszta és zavaró elemektől mentes, A legördülő és 
felbukkanó menük további lehetőségeket rejtenek. Ezen 
kívül rengeteg hasznos gyorsbillentyű segíti munkánkat, 
felderítésükhöz az ardour -b parancsot kell kiadnunk az 
xterm parancssorában. 

Miután kicsit magabiztosabban mozogtam az Ardour alap- 
képességei között, elkezdtem felfedezni a további képessé- 
geit. A TM-D1000 MIDI üzeneteket és vezérlőfolyamokat 
küld a legtöbb művelet végrehajtásakor, az Ardour vezérlő- 
jét pedig külső MIDI vezérlőfelülethez is rendelhetjük. 

A gombon vagy kioltón a ctrl--középső egérkattintással 
majd a vezérlő aktiválásával tudjuk hozzárendelést elvé- 
gezni. Ez a képesség nagyon hasznos, hiszen segítségével 
bármely, MIDI vezérlőfolyamokat küldő külső egység fel- 
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5. ábra Opció ablak 


használható Ardouwr vezérlőfelületként. Mellesleg, a csopor- 
tosítás ilyenkor is érvényes, így az Ardourban akár több ki- 
oltót is kezelhetünk egyetlen külső kioltóval. 

A TM-D1000 képes MIDI gépi vezérlő parancsokat (MIDI 
machine control, MMC) értelmezni és küldeni, ami igen 
hasznos képesség, ugyanis az Ardour képes vezérelni illetve 
vezérlehető az ilyen eszközökről. Az MMC üzenetek olyan 
általános átvitelvezérlési műveleteket irányítanak, mint az 
indítás/leállítás, gyors-tekerés és visszacsévélés. Így egy 
MIDI-érzékeny mixer, például a TM-D1000-es, szinte az 
összes Ardour művelet vezérlőfelületeként felhasználható. 
Egy ilyen terjedelmű cikkben csak a céloknak leginkább 
megfelelő képességeket tudtam kipróbálni. Még nem dol- 
goztam az Ardour ciklus-rendszerével, az MTC a cikk készí- 
tése közben fejeződött be, nem ellenőriztem az időnyújtási 
képességet sem, és így tovább. Mint említettem, az Ardour 
igen nagy tudású alkalmazás, és cikkünkben rengeteg érde- 
kes és hasznos képességet még csak nem is érintettünk. 


A jövő 

Az Ardoxr fejlesztési aktivitása igen viharos, különösen 
most, hogy a program közeledik az 1.0 -ás kiadáshoz. Sok 
ember érdeklődik egy versenyképes alternatíva iránt a más 
operációs rendszereken megszokott üzleti zárt megoldások 
helyett, és az Ardour úgy tűnik a helyes fejlesztési ösvényen 
halad. Még igen sok munkára lesz szükség, ideértve a MIDI 
képességek továbbfejlesztését, videó követés támogatását, 
kiterjesztett szinkronizálást és a GUI nagyjavítását (GTKZ2 tá- 
mogatást terveznek). Ugyanakkor jelenleg az Ardour képes- 
ség fagyasztás alatt áll, az elsődleges szempont a hibajavítá- 
sok és a stabilitás elérése az 1.0-ás verzió kiadása előtt. 

Mint azt egy komolyabb összetett projekt pre-1.0 béta vál- 
tozatától megszokott, ez sem teljesen hibátlan. Az Ardour 
Mantis hibakövető és képességkérő rendszere viszont 
kiváló lehetőséget biztosít egy ismert hiba állapotának 
ellenőrzésére, új hibák jelzésére, vagy a kívánt képességek 
iránti igény bejelentésére. 

A VST bővítmények támogatása jelenleg kicsit problémás, 
ami legfőképpen a WINE és a Linux rendszermag folyama- 
tos fejlesztésnek tudható be, de ezt a kérdés is előkelő he- 
lyet foglal el a fejlesztők listáján. Sok felhasználó jelezte, 
hogy hajlandó lenne platformot váltani, ha a VSTI/VSTi 
támogatás zökkenőmentesen működne Linux alatt. 


A VST/VSTi bővítmények 

A VST/VSTi audio bővítmények rendkívül fontosak a hang- 
programok világában. A VST API-t a népszerű Cubase 
audio/MIDI szekvencer készítője, a Steinberg cég készítette, 
amely később világszerte elterjedt a fejlesztők és a felhasz- 
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nálók között. Pontosan fogalmazva a VST bővítmény álta- 
lában egy hang vagy MIDI feldolgozó, a VSTi bővítmény 
pedig egy hangszer mint a szintetizátor vagy a dobgép. 
Manapság több ezer VSTI/VSTi bővítmény létezik a házi 
készítésűektől kezdve a drága üzleti megoldásokig. 

Sok, igen jó minőségű ingyenes VST bővítmény létezik, 

sőt néhány VST szerző saját bővítményét teljesen szabad, 
nyílt forrású programként is kiadta a GPL engedélye alatt. 
Az Ardour dokumentációja szintén érdekes kérdés, ugyanis 
jelenleg nincsen hivatalos felhasználói kézikönyve. Paul 
Davis a további fejlesztések során is valószínűleg ingyene- 
sen fogja elérhetővé tenni az Ardourt, és csak a jó minőségű 
kézikönyvért kér majd ellenszolgáltatást. Addig is a merev- 
lemezes rögzítők alap tervezési kérdéseiben nem annyira 
járatos felhasználóknak érdemes beszerezni és tanulmá- 
nyozni valamelyik üzleti DAW, például a Pro Tools vagy 
dokumentációt találhatunk a forráscsomag szöveges állo- 
mányaiban és különböző hálózati forrásokban, például 

a Ouick Toots sorozatban (lásd a forrásokat), valamint az 
ardour-users és ardour-dev levelezőlisták forgalmában. A fej- 
lesztők és tesztelők az ffardour IRC csatornán beszélgetnek, 
az egyéb felhasználók Ardour-vonatkozású kérdéseiket az 
AGNULA/Demudi, Planet CCRMA, ALSA és Linux Audio 
Users csoportban tehetik fel. 

Készen áll vajon az Ardour a nagy dobásra? Talán még 
nem teljesen, de az útirány egyértelműen arrafelé mutat 

és a hátralévő út sem lehet már túl hosszú. Úgy gondolom, 
már csak rövid ideig kell várnunk és az Ardowr az élvonal- 
beli üzleti audio-program világot is szemöldökfelvonásra 
készteti majd. Az Ardourt már ma is használják teljes CD 
projektek rögzítésére és keverésére, és egyre több felhasz- 
náló számol be arról, hogy sikeresen használta az Ardourt 
saját rögzítési projektjében. Úgy tervezem még rengeteg 
zenét készítek az Ardour-al. Bárki nyugodtan látogassa 
meg a honlapomat és szemezgessen az alkalmi szerze- 
mények között. 


Köszönetnyilvánítás 

A szerző köszönetét és mély elismerését küldi Paul Davis- 
nek, Taybin Rutkinnak, Jesse Chappellnek, Steve Harrisnak 
és az Ardour fejlesztőcsapat többi tagjának. Munkájuk az 
Ardoutrban és sok más értékes Linux audio projektben ko- 
moly újítás és igazi munkaszeretetről tanúskodik. A világ 
szabad zenészei tisztelegnek előtettek! 

Nagy köszönet illeti az Ardour felhasználók levelezőlistáját, 
különös tekintettel Jan Depner, Mark Knecht, Aaron Trumm 
és Josh Karnes urakat. A fejlesztők és felhasználók nagyon 
segítőkészek voltak, és amikor elakadtam az Ardour trük- 
kösebb részeinél a jó társaság igencsak megkönnyítette 

a nehézségeket. 


Linux Journal 2005. március, 131. szám 


5] Dave Phillips az Ohioi Findlay-ben élő zenész, 
§ tanár és író. Linuxszal való eslő, 1995-ös talál- 
kozása óta tagja a Linux Audio közösségnek. 

Ő a s zerzője a The Book of Linux Music § 

] Sound című könyvnek valamint Linux Journal 
számos cikkének. 
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GNU Motion: A számítógép termek mindent 


látó szeme 


Lehet, hogy jól néz ki az ajtónk, de biztosan szükségünk van 23 órányi videó- 
anyagra ahol zárva látjuk? A következő program használatával biztonsági videó- 
inkból kigyűjthetjük a lényeges részeket és kiszúrhatjuk a be- és kilépéseket. 


gép felszerelésekkel teli szobánk. Ez igazán olyasmi 

amin érdemes rajta tartani a szemünket, nem igaz? 
Fel is rakunk egy hálózati csatlakozással ellátott kamerát. Ettől 
kezdve csak a kamera honlapjára kell benéznünk és máris 
látjuk mi is történik a kiszolgálóteremben éjjel és nappal. 
Ez már haladás, de hamarosan rájövünk, hogy valamilyen 
rögzítőeszközre is szükség lenne, hátha esetleg ki kell találni, 
ki is volt a szobában az utolsó csütörtökön. Ezért aztán el- 
kezdjük menteni a videóanyagokat a hálózat másik rendsze- 
rére, hogy aztán szükség esetén visszanézhessük őket. Esetleg 
írunk néhány parancsfájlt, amelyek mondjuk hetente lecseré- 
lik a felvételeket, hogy azok ne töltsék fel a merevlemezt. 
Miután hosszú órákon át bámuljuk a videót, hogy végül 
ráakadjunk ki vette ,kölcsönön" kedvenc csavarhúzónkat, 
hirtelen ráébredünk, itt bizony további finomításokra lesz 
szükség. Hát nem lenne sokkal jobb, ha a számítógép csak 
az érdekes videórészeket tartaná meg, a többit pedig kidob- 
ná? Nos, használjuk a GNU Motion-t, ezt az ingyenes moz- 
gásérzékelő programot. Dolgozzuk fel vele a videóinkat és 
a napi 24 órás felvételeink 15 perces klippé zsugorodnak, 
rögzítve minden pillanatot amikor valami megmozdult 
a szobában - éljen a technika. 


T együk fel, hogy van egy több ezer dolláros számító- 


Alkatrészigény 

A GNU Motion önálló webkamerákkal is tud dolgozni (ilye- 
neket árul például a hálózati forrásokban található Axis), 
illetve használhatunk bármilyen, video4linux-kompatibilis 
rögzítőkártyához kapcsolt kamerát. Itt most az Axis 2100-as 
önálló kamerán alapuló megoldásra fogunk koncentrálni, 
ugyanis ezt egyszerűbb beállítani. Mindkét esetben szükség 
lesz egy Linux rendszerre, amely a videó anyagot elmenti 
és futtatja a Motion-t. A Motion elég komoly feldolgozóerőt 
kíván, de egy Pentium III processzorral rendelkező vagy 
annál erősebb gép megfelelő lehet, különösen ha kizárólag 
a Motion futtatására használjuk. 

Az Axis kamera telepítése és beállítása nem túl bonyolult. 
Keressünk neki egy jó helyet a megfigyelendő szobában, 
majd vezessünk be az áramot és az Ethernet kábeleket. 
Tapasztalataim szerint valamivel szemmagasság felett, 7 láb 
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magasan a szoba sarkában elhelyezett kamerával érhetjük 
el a legjobb lefedettséget. Kövessük a kamera telepítési út- 
mutatóját és rendeljük a hálózatunk valamelyik IP számá- 
hoz. Ellenőrizzük a kamera helyes működését, majd irá- 
nyítsuk a böngészőnket a kamera weblapjára. A videó- 
tárolásra és a Motion futtatására használt gép tetszés szerin- 
ti helyre kerülhet. Az egyszerűség kedvéért talán érdemes 

a kamerával azonos logikai vagy fizikai hálózatra helyezni. 


Programigény 

Bármely modern Linux terjesztés megteszi. Saját megoldá- 
somban Fedora Core 1-et használok. 

Töltsük le a Motion honlapjáról a Motiont (lásd a forráso- 
kat). Az írás születésekor a 3.1.16-os volt a legfrissebb ver- 
zió. Felhasználhatjuk a Motion weblapján található RPM 
csomagot de lefordíthatjuk forrásból is. Máshonnan lesze- 
dett RPM és Debian csomagok telepítését nem igazán javas- 
lom, ezek ugyanis általában idejétmúltak és hiányzik belő- 
lük egy-két képesség. A Motion fejlesztésének néhány 
hónapja alatt elég sok fontos változás történt. 

Az egyetlen külső programfüggőség az ffnpeg könyvtár, 
amelyet a Motion az MPEG videók készítésére használ. 

Az ffmpeg 0.4.8-as kiadott verzióját kell használnunk, 
ugyanis az újabb, fejlesztési verziók mellett a Motion nem 
működik helyesen. Töltsük le az ffnpeg forrását (lásd a for- 
rásokat); ffmpeg könyvtárat a Motion telepítése előtt kell le- 
fordítanunk és telepítenünk. Ha nem így teszünk a Motion 
megpróbálja a régebbi, mpegplayer nevű eszközzel létre- 
hozni a videókat. Mivel legtöbbünknél valószínűleg ez 
sincs telepítve, a Motion nem igazán fog jól működni. 


Program fordítás 

Miután letöltöttük a Motion-t és az ffmpeg-et, kicsomagoljuk 
őket például a /tmp könyvtárba. Lépjünk cd-vel az ffmpeg 
forráskönyvtárába és adjuk ki a következő parancsokat: 

$ ./configure 

$ make 

tf make install 


Az utolsó parancsot root-ként kel kiadnunk. 








A parancsok a /usr/local/lib könyvtárba helyezik el az 
ffmpeg programkönyvtárat. Ezek után lépjünk be a Motion 
forráskönyvtárába és ismét futtassuk le a . /configure pa- 
rancsot. Ezúttal azonban ellenőrizzük le az eredményt. Fon- 
tos, hogy a Configure Status, FFmpeg Support mellett Yes vá- 
laszt lássunk. Amennyiben nincs így, a Motion nem találta 
meg az ffmpeg könyvtárat a rendszerünkön. Ez a Motion 
telepítésekor fellépő hibák és kavarodások elsődleges oka. 
Ne is folytassuk, amíg meg nem oldottuk ezt a éproblmát. 
Keressük meg, hogy a rendszerünk hol tárolja a libavcodec- 
0.4.8.so állományt, majd a Motion könyvtárban futtassuk 

le ismét a configure-t: 

$ ./configure --with-ffmpeg-/valamilyen/elérési/út 


Ha a configure futtatása után azt látjuk, hogy FFmpeg 
Support: Yes, akkor végre lefordíthatjuk és telepíthetjük 
a Motiont: 

$ make 

tf make install 


Akárcsak az előbb, az utolsó parancsot rootként kell futtat- 
ni. Ha elkészültünk, a /usr/local/bin/motion végrehajtható 
állomány a rendelkezésünkre áll. 

Amennyiben a telepítés során problémákba ütköznénk, 
nézzünk utána a Motion Guide (lásd a forrásokat) oldalain. 
A kézikönyv bizonyos részei kicsit elavultak, de hasznos in- 
formációkat tartalmaz a Motion telepítésével és futtatásával 
kapcsolatban. 


Motion beállítása 

A Motion démonként fut, folyamatosan analizálva és tárolva 
a videóanyagot. Vezérlését a szokásos UNIX mintának meg- 
felelően egy beállításfájl végzi. Másoljuk át a forráskönyvtár 
motion-dist.conf állományát az /etc/motion.conf helyre, majd 
szerkesszünk át néhány paramétert. Az első, amit meg kell 
változtatnunk a netcam ur1 beállítása. A Motion ezen 

az URL-en keresztül kapja a JPEG képeket a kameráról. 

Az Axis 2100 kamera esetében ez a következő alakú lesz: 
http: //netcam. example . com/axis- 

cgi/jpg/image . cgi ?resolution-640x480 


Miután a motion.conf állományban beállítottuk 

a netcam ur1 változót, a közvetlenül csatlakoztatott kame- 
rákra vonatkozó beállításokat (videóeszköz, forgatás, 
magasság, szélesség) figyelmen kívül hagyja a rendszer. 
Nem árt ha tudjuk, hogy a netkameráknak van egy hátrá- 
nyuk a szokásos videó felvevő eszközökkel szemben. 
Jelenleg a Motion csak egyetlen JPEG képet tud egyszerre 
lekérni a netkameráktól, ezáltal a videónk maximum 12-15 
képkocka per másodperc (fps) sebességre korlátozódik. 
Dolgoznak rajta, hogy a képeket motion-jpeg folyamként 

is le lehessen tölteni a kameráról, de ez a munka még nem 
fejeződött be. Gyakorlatban azonban 10 vagy I2íps tökéle- 
tesen elegendő a szoba felügyeletéhez. 

Szükségünk lesz egy eszközre is ahol a Motion készítette 
videókat tárolhatjuk. Én általában a /var/log/vcr könyvtárat 
használom a Linux kiszolgálómon. A használt elérési út 
természetesen a lemezhely lehetőségeinktől is függ. Ideális 
esetben egy külön fájlrendszert tudunk nyitni a Motion 
videóknak, amivel elkerülhetjük, hogy a gyökér vagy a /var 
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fájlrendszert videó fájlokkal töltsük fel. Ezt a könyvtárat 

a target dir változóval adhatjuk meg a motion.conf-ban. 
Következő lépésben adjuk meg a készítendő videó típusát. 
A Motion 3.1.16 az MPEG1, MPEG4 és MS-MPEG4 formá- 
tumokat támogatja. Az MPEG1 előnye, hogy egyszerű és 
jól támogatott formátum. Az MPEG4 ugyanakkor szebb 
képet és jobb tömörítést biztosít. Az utolsó formátumot, 

az MS-MPEG4-et pedig a Microsoft Windows Media Player 
további kiegészítő bővítmények nélkül is képes értelmezni. 
Figyelem: az MPEG4 és MS-MPEG4 támogatás a Motion 
3.1.16-os verziójában jelent meg, így nincs olyan részletesen 
tesztelve mint az MPEG1 videó kezelése. Nálam azonban 
az MS-MPEG1 jól bevált, és a Windows felhasználóknak 
egyszerűbb megnézni. Az MPlayerrel vagy más modern vi- 
deó lejátszóval tetszőleges formátumú videókat nézhetünk 
Linux rendszeren. 

A videó típusát a ffmpeg. video. codec változó vezérli 

a motion.conf állományban. 

Ennyi alapinformációval már el tudjuk kezdeni a Motion 
használatát. Ellenőrizzük, hogy a output. normal off-ra 
legyen állítva, ugyanis különben az összes képkocka JPEG 
képe a target dir könyvtárba kerül. Ez később jól jöhet 

a hibakeresésénél, de jelenleg csak felesleges teher. 


A Motion indítása 

Indítsuk el a Motion-t root-ként a parancssorból: /usr/local/ 
bin/motion. A Motion remélhetőleg elindul és megkezdi mű- 
ködését. Ha azonnal kilépne akkor valószínűleg hibát ejtet- 
tünk a beállításállományában. Hibakeresésben segít a hiba- 
üzenet. Miután sikerült elérnünk, hogy a Motion elinduljon 
és fusson, hozzunk létre valami bemenetet. Sétáljunk a ka- 
mera előtt, vagy ami még jobb, kérjünk meg valakit, hogy 
tegye ezt meg. Ne feledjük el felgyújtani a lámpákat a szo- 
bában, különben a kamera nem fog túl sok mozgást észlelni. 
Ahogy a kamera előtt megindul a mozgás, a Motion elkezd 
kimeneti állományokat készíteni. Ha a tevékenység befeje- 
ződött, ellenőrizzük, hogy keletkeztek-e állományok 

a targer dir könyvtárban. Nézzük meg az állományt 

a videólejátszónkkal. A videó döcögősnek tűnhet, hiszen 
csak állóképeket szedegetünk a netkameráról. A Motion ki- 
tölti a hiányzó képkockákat, így a videó normál sebességgel 
fut, a minősége pedig hozzávetőlegesen megfelel a kiske- 
reskedésekben megfigyelhető kamerák minőségének. Ha 
minden jól ment ideje beállítanunk, hogy a Motion minden 
rendszerindításkor elinduljon. 

A Motion-t egy init parancsfájl készítésével futtathatjuk 
minden rendszerinduláskor. A Red Hat-alapú rendszereken 
a motion.init állományt másoljuk a Motion forráskönyvtá- 
rából a /etc/init.d/motion könyvtárba majd rootként futtas- 
suk le a következő parancsokat: 

ft /sbin/chkconfig --add motion 

ft /sbin/chkconfig motion on 


Ezek után kézzel lefuttatva próbáljuk ki, hogy a behúzófájl 
valóban működik-e: 
/etc/init.d/motion start 


Végül, aki igazán súlyos üldözési mániában szenved, az in- 
dítsa újra a rendszert és ellenőrizze, hogy a Motion valóban 
elindul és működik-e újraindítás után is. 
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Beállítások hangolása 

Mint minden jó linuxos program a Motion is rendelkezik 
néhány finomhangolható képességgel. A legjobb tanács 
amit a Motion hangolásakor adhatunk, hogy csak egy válto- 
zót változtassunk meg, majd indítsuk újra a Motiont és pró- 
báljuk ki. Néhány beállítási változó nem egészen egyértel- 
mű hatást gyakorolhat a többire. 

Első lépésként érdemes bekapcsolni a locate és 

text. changes motion.conf változókat. A locate minden 
képkockán dobozt rajzol megtalált mozgás köré, 

a text changes pedig a kép sarkában kiírja a megváltozott 
pixelek számát képkockánként. Ezzel a két beállítással 
könnyen kitalálhatjuk, hogy a kép melyik részéről gondolja 
a Motion, hogy mozog, illetve ott mennyi mozgás van (azaz 
mennyi pixel változott meg a képen). 

Azonnal észrevettem, hogy valószínűleg nem túl jó helyre 
tettem a kamerát a kiszolgálóteremben. A szobának ugyanis 
volt egy ablaka, amely egy másik irodahelységbe nézett. 
Eltartott egy ideig míg kiderítettem, hogy miért kapok annyi 
apró Motion filmet amikor az egyetlen mozgás a szoba apró 
árnyalat és megvilágítás változása volt. Végül rájöttem, hogy 
a másik szobában található világos színű ajtó kinyitásakor 
időnként fény vetül az ablakon keresztül a kiszolgálóterembe. 
Ez a fény verődik vissza a fém légkondicionáló fényes felüle- 
téről a kamerába. Így aztán, bár a kamera egyáltalán nem lát- 
ta az ablakot, a rávetülő fény mégis hamis jelzéseket okozott. 
Visszatekintve, úgy kellett volna elhelyezni a kamerát, hogy 
ne nézzen külső fényforrások és fényes fémfelületek felé. 
Végül mégis inkább úgy döntöttem ott hagyom ahol van, 
hiszen tényleg ez volt a legjobb hely ahonnan be lehetett 
látni az egész szobát. A kamera mozgatása helyett, inkább 

a Motion-t módosítottam egy kicsit. 

Először is létrehoztam egy maszkállományt. Ez a kamera ki- 
menetével azonos (tehát az Axis esetében 640 x480) méretű, 
egyszerű fekete fehér kép. A fekete részeket a Motion fi- 
gyelmen kívül hagyja. Az állományt a The GIMP segítségé- 
vel készítettem és kifeketítettem a légkondicionáló fémré- 
szeinek megfelelő területeket. Sajnos a Motion elég váloga- 
tós e fájl tekintetében; nyers és nem ASCII, hordozható 
szürke skálás (PGM) állományként kell kimentenünk. 

A Motion nem kedveli a The GIMP által létrehozott PGM 
állományokat. Ha egy ilyet használunk, a Motion ugyan 
elindul, azonban hamar kilép a következő üzenettel: 

This is not a ppm file, starts with "P6" 


Néhány perces forráskód nézegetés után kiderült a hiba 
oka. A Motion azt szeretné, hogy a PGM állományok elején 
található verziószám P6 helyett P5 legyen. Szerkesszük át 

a maszk állományunkat és írjuk át az elején lévő mágikus 
számot P6-ról P5-re. Az állományt nyugodtan szerkeszthet- 
jük vi-ban. A változtatás után a Motion gond nélkül beol- 
vassa az állományt. 

A módosítás csökkentette, de nem szüntette meg az üres 
felvételeket. Ezért egy másik módosításhoz fordultam. Meg- 
próbáltam beállítani a villanykapcsoló (light switch) para- 
métert, amely a motion.conf megjegyzése szerint segíthet 
kiszűrni a hirtelen fényváltozásokat. Ezt teljesen hatásta- 
lannak találtam. Megpróbálkoztam a rögzítéshez szüksé- 
ges megváltozott pixelek számának csökkentésével is. 

A text changes kimenete jól jött ilyenkor, hiszen minden 
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egyes képkockára kiírta a megváltozott pixelek számát. 
Amennyiben a Motion túlságosan sok hibás filmet ment ki, 
megpróbálhatjuk a text. changes által kiírt értékek fölé 
emelni a határértéket. 

Végül a legjobb megoldásnak a motion minimum frames 
érték megnövelése bizonyult. Ez azoknak a képkockáknak 
a számát jelenti, amelyeken változásnak kell lennie, hogy 

a Motion elkezdjen filmet készíteni. Ezt az értéket háromra 
állítva úgy találtam, hogy a fényváltozásból adódó legtöbb 
hamis film eltűnt. A legtöbb ilyen film ugyanis csak néhány 
képkocka hosszú volt, hiszen a fényváltozás egészen hirte- 
len történt. Ezzel szemben a valódi mozgás események álta- 
lában sok képkockán keresztül tartanak. Így, ha rengeteg 
egy-két másodperces apró filmet találunk, javaslom emel- 
jük meg a motion minimum frames értékét legalább három- 
ra, esetleg még többre. 


További fejlesztések 

További egyelőre csak terv szinten létező, nem-program fej- 
lesztési ötletem, hogy mozgásérzékelőt szerelünk be a szer- 
verszoba villanykapcsolójának működtetéséhez. Ezzel ügye- 
sen megoldanánk, hogy mindig legyen elég fény a szobában 
a Motion felvételeihez. Valami történik a szobában, a fény 
felgyullad, a Motion pedig rögzít. Mozgásérzékelő lámpakap- 
csolók 15 dollár körüli összegért kaphatóak a kereskedések- 
ben és csak alapvető villanyszerelési ismereteket igényelnek. 
Egyelőre egyszerűen csak hagyom a /var/log/vcr tároló- 
helyen felgyűlni a filmeket, aztán időnként kézzel törlöm 
őket. Elképzelhető, hogy lenne értelme automata módszert 
is kidolgozni az ilyesmi kezelésére. Jelenleg úgy gondolom, 
hogy a filmeket 30 naponta érdemes törölni. Nyilvánvalóan 
ez az egyedi igényektől függ. 

A levelezőlistán mostanában jelent meg néhány kísérleti 
mjpeg támogatási folt. Mint korábban említettem az mjipeg 
azt jelenti, hogy a Motion állandó képfolyamot kér le a ka- 
meráról és nem egyesével tölti le azokat. Ezzel sokkal folya- 
matosabb videókat készíthetünk, bár a nettkamerákból 
származó mostani Motion videók amolyan igazi Keystone 
Kops hangulatot keltenek. A GNU Motion aktív fejlesztése 
tovább folyik. A levelezőlista (lásd a forrásokat) kiváló hely, 
ha valaki kérdéseket szeretne feltenni vagy a fejlesztésről 
érdeklődik. A Motion-nel kapcsolatos tudásom nagy részét 
a levelezőlista archívumát böngészve szereztem. 


Osszefoglalás 

A GNU Motion a számítógépipar egyik legbosszantóbb 
problémájára, az adattúltengés gondjaira kínál megoldást. 
Mi értelme a rengeteg videó-felvételnek, ha több van belő- 
le, mint amit valaha is meg tudnánk nézni? Egy kis kép- 
vizsgálat segítségével a Motion hamar kiszűri az unalmas, 
változatlan videofelvételeket, melyek senkit sem érdekel- 
nek. Az eredmény: hatékonyabb kiszolgálóterem megfigye- 
lés és több idő amit a projektjeinkre fordíthatunk. 


Linux Journal 2005. március, 131. szám 
A cikk forrásai: 5 www.linuxjournal.comj/article/7966 


Phil Hollenback 
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Központi, címtárszolgáltatás alapú 


jogosultságkezelés 22. rész) 


Ki és hova jelentkezhet be? Megbízható, központi címtárral ennek szabályozása 


nem okozhat gondot. 


jogosultságkezelés az a folyamat, amelynek so- 
A rán eldöntjük, hogy X entitás, jellemzően egy 

személy, jogosult-e az Y erőforrás használatára. 
X vizsgálata meghatározása a hitelesítési folyamat feladata. 
A számítógépes hálózatokban a jogkezelés egyik lépése 
annak meghatározása és ellenőrzése, hogy az egyes fel- 
használók a hálózat mely számítógépeihez kaphatnak 
hozzáférést. Egyszerű példaként a számítógép /etc/passwd 
fájljában lévő janos:X:1234:56: /home/janos : /bin/bash 
sor említhető, amely a janos nevű felhasználónak hozzá- 
férést ad a helyi géphez. Ha a janos nevű felhasználónak 
több számítógép használatára szeretnénk jogot adni, akkor 
az összes gép /etc/passwd fájljához hozzá kell adnunk 
a fenti sort. 
Linux alatt jellemzően minden olyan felhasználó, aki jogot 
kap a helyi számítógépre való bejelentkezésre, helyi fiókkal 
rendelkezik. Ez arra is visszavezethető, hogy a felhaszná- 
lóknak nemcsak bejelentkezési jogot kell kapniuk, de mun- 
kájuk elvégzéséhez további erőforrásokhoz, például a kez- 
dőkönyvtárukhoz is hozzá kell férniük. Ha minden számí- 
tógépen létrehozzuk a megfelelő helyi fiókokat, akkor ez 
a kérdés megoldottnak tekinthető. 
A helyi fiókokra épülő megoldással az a baj, hogy a fió- 
kok egységessége nem biztosított. Azonos felhasználó- 
névhez egy másik gépen másik felhasználóazonosító 
és/vagy csoportazonosító tartozhat. Ennél is nagyobb gon- 
dot jelent, ha különböző gépeken két különböző fiókhoz 
azonos felhasználóazonosító és csoportazonosító tartozik. 
Lehetséges például, hogy a janos nevű felhasználó az 1-es 
számítógépen az 1234 felhasználóazonosítót és az 56 cso- 
portazonosítót kapja, míg a julia nevű felhasználóhoz a 
2-es számítógépen ugyancsak az 1234 felhasználó- és az 56 
csoportazonosító tartozik. Ez a felállás megosztott erőfor- 
rások használatakor komoly biztonsági kockázatot jelent. 
Például egy NFS-kiszolgáló számára a két fiók azonosnak 
látszik, tehát a két felhasználó akadálytalanul törölheti 
egymás fájljait. 
A egységesség problémáján úgy lehetünk úrrá, hogy 
minden szükséges információt egyetlen központi hitelesíté- 
si adatforrásból veszünk, természetesen biztosítva a számí- 
tógépeknek a hozzáférést ehhez a forráshoz. A címtárszol- 
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gáltatások pontosan ezt a célt szolgálják. Napjainkban 

a két legelterjedtebb, központi hitelesítésre használt cím- 
társzolgáltatás a NIS (hálózati információs szolgáltatás, 
network information service, korábban yellow pages, azaz 
sárga oldalak, röviden YP névvel futott) és az LDAP 
(lightweight directory access protocol, egyszerű címtárelérési 
protokol. 


A NIS és az LDAP összehasonlítása 

Amikor arra a kerül a sor, hogy ki kell választanunk, cím- 
társzolgáltatásként a NIS-t vagy az LDAP-t használjuk, 
nem árt néhány tényezőt figyelembe vennünk. Ha cégünk 
már rendelkezik LDAP-kiszolgálóval, akkor egyszerűnek 
adatokkal. Csakhogy a vállalati LDAP-kiszolgálókat álta- 
lában névjegyek tárolására és hasonló, valóban egyszerű 
feladatokra használják. A jogkezelési adatok hozzáadása 
komoly terhelést róna a kiszolgálóra, hiszen a programok 
által indított, felhasználónév, felhasználóazonosító, cso- 
portazonosító stb. lekérdezésére irányuló kéréseket mind 
meg kell válaszolnia. Általában érdemesebb egy további, 
kizárólag a jogkezeléssel foglalkozó LDAP-kiszolgálót 
üzembe állítani. A címtár felé irányuló lekérdezések sok- 
színűsége miatt a teljesítmény hangolása is rendkívül 
nehéz. A gyakoribb lekérdezéseket úgy gyorsíthatjuk 

fel, hogy az összes szükséges LDAP indexmegadást hoz- 
záadjuk a slapd.cont fájlhoz, ám túlságosan sok index- 
megadást sem célszerű hozzáadni, mert ezzel az LDAP 
adatbázisfájljainak növekedését okozzuk, ami miatt 
viszont újfent csökkenni fog a sebesség. 

Az LDAP azokban a hálózatokban nyújt jobb megoldást, 
ahol sok UDP-csomag vész el, ugyanis TCP/IP alapú, vagyis 
az újraküldések elvégzését a hálózati rétegre bízza. A NIS 
ezzel szemben UDP feletti távoli eljáráshívást (remote 
procedure call, RPC) alkalmaz. Esetében minden eldobott 
csomag egy válasz nélkül maradt NIS-lekérdezést jelent, 
amelyet az ügyfélnek meg kell ismételnie. Azt, hogy háló- 
zatunkra mennyire jellemző a csomagvesztés, a netstat -s 
-u parancsot különböző gépeken, különböző időpontokban 
kiadva vizsgálhatjuk meg. Jó esetben a parancs csak elenyé- 
sző számú hibát jelez. 
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Írásomban elsősorban a NIS-sel foglalkozom, mivel 
üzembe helyezése rendkívül egyszerű, és ha elégedetle- 
nek vagyunk vele, akkor rendkívül könnyen áttérhetünk 
róla az LDAP használatára. A PADL Software Pty, Ltd. 
több nyílt forrású, a NIS adatfájlok LDAP fájlokká alakí- 
tására alkalmas programot is készített. (Lásd az internetes 
forrásokat.) A teljesítményhangolás természetesen min- 
denképpen ránk marad. Ha LDAP-ról akarunk NIS 
használatára áttérni, akkor az átalakítást magunknak 

kell megoldanunk. 


A NIS-kiszolygálók beállítása 

A NIS-kiszolgálók nem igényelnek komolyabb hardve- 
res erőforrásokat. Gyakorlatilag bármilyen átlagos gé- 
pen futtathatók. Ugyanakkor a szolgáltatást érdemes 
lehet külön gépre telepíteni. Nálunk, a Stanford Linear 
Accelerator Centerben (SLAC) 500 Linuxot és Solarist futta- 
tó ügyfélgépet szolgálunk ki egyetlen régi Sun Netra T1 
géppel. Négy NIS-kiszolgáló szolgálja ki 700 Solaris és 
Linux alapú asztali számítógépünket, és további hat 

a körülbelül 2500 darab, szintén Solaris és Linux alapú 
számítási kiszolgálót. Az ügyfelek nem teljesen egyen- 
letesen oszlanak el a kiszolgálók között. 


A mester kiszolyáló beállításai 

Jelentkezzünk be arra a gépre, amelyre telepíteni szeret- 
nénk a mester NIS-kiszolgálót, majd ellenőrizzük, hogy 

a legújabb portmap, ypserv és yp-tools RPM-ek telepítve 
vannak-e. Ha nem, töltsük le és telepítsük őket. Az alábbi 
parancsokat kivétel nélkül rootként kell kiadni. Indítsuk el 
a portmapper démont: 


4 service portmap start 


A következő lépés új NIS-tartományunk nevének meg- 
adása. A név tetszőleges, de nyilván érdemes olyat válasz- 
tani, ami tükrözi cégen belüli szervezetünk, részlegünk 
nevét. Ha például nmis.pelda.com a teljes pelda.com NIS- 
tartománya, akkor a tervezési részleghez választhatjuk 

a terv.pelda.com-ot. 

A mester kiszolgálón a NIS-tartománynevet a következő 
paranccsal állíthatjuk be: 


ff domainname nis.pelda. com 

A következő sort: 

NISDOMAIN-nis . pelda. com 

pedig a /etc/sysconfig/network fájlhoz kell hozzáírnunk. 


A NIS-kiszolgáló elérhetőségét egy /var/yp/securenets nevű, 
alábbi tartalmú fájl létrehozásával korlátozhatjuk: 


$ network 
192.168.0.0 


$ netmask 
2559.2595.255.0 


Ez egy fontos biztonsági lépés, ne feledkezzünk meg róla! 
Ha ezt a fájlt nem hozzuk létre, bárki képes lesz lekérdezé- 
seket intézni NIS-kiszolgálónkhoz. 
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Haladjunk tovább: meg kell határoznunk, milyen adatokat 
akarunk NIS alatt tárolni. Jogosultságkezelési célokra a /etc/ 
group és a /etc/passwd fájl, továbbá egy netgroup nevű 
dolog elegendő lesz. Ennél azonban sokkal többre is van 
lehetőség. Ötleteket a NIS-kiszolgáló /var/yp/ Makefile fájl- 
jából lophatunk. 

Az alábbiakban bemutatom, hogyan történik az említett há- 
rom fájl NIS segítségével végzett terjesztésének beállítása. 
Módosítsuk a NIS-térkép adatbázisfájljait létrehozó 
Makefile-t: 


ft cp /var/yp/makefile /var/yp/makefile.save 
ff vi /var/yp/Makefile 


Az alábbi két beállítás értékét true-ról false-ra változtatva 
megakadályozhatjuk a passwd és a shadow, illetve a group 
és a gshadow fájlok egyesítését: 


MERGE. PASSWD-false 
MERGE. GROUP-false 


Módosítsuk a NIS adatforrásait tartalmazó könyvtárak 
nevét: 


YPSRCDIR 
YPPWDDIR - 


/etc/NIS 
/etc/NIS 


Azokat a fájlokat, amelyekből nem akarunk NIS adatbázi- 
sokat készíteni, tegyük megjegyzésbe. Én csak az alábbi 
hármat hagytam meg: 


GROUP - $(YPPWDDIR) /group 
PASSWD - $(YPPWDDIR)/passwd 
NETGROUP - $(YPSRCDIR)/netgroup 


Az all: kezdetű, az összes lehetséges NIS-térkép listáját 
tartalmazó bejegyzést tegyük megjegyzésbe. Adjuk hozzá 
az alábbi új sort: 

all: passwd group netgroup 

Ügyeljünk a tabulátorokra! A Makefile fájlokban a pa- 
rancsok igazítására kizárólag tabulátorokat használjunk, 
szóközöket ne. 

Hozzuk létre a Makefile-ban megadott adatforrás 
könyvtárat: 


$ mkdir /etc/NIS/ 
ft chmod 700 /etc/NIS 


majd helyezzünk bele egy passwd fájlt: 
f grep -v "Aroot" /etc/passwd 5 /etc/NIS/passwd 


A fájlból vegyük ki a root fiókot, valamint az összes egyéb 
rendszerfiókot; kizárólag a valódi felhasználói fiókokat 
hagyjuk meg benne. 

Ha a /etc/passwd-t még mindig használjuk titkosított 
jelszavakkal, akkor itt az ideje, hogy az előző cikkben 
(Linuxvilág, 2005. március) ismertetett módon áttelepít- 








sük őket Kerberos 5 alá. Ha ezt nem tesszük meg, akkor 

a titkosított jelszavak hozzáférhetőkké válnak, amikor 

a passwd fájlt továbbadjuk a szolga NIS-kiszolgálók 

vagy a NIS-ügyfelek felé. 

Gyűjtsük össze a helyi /etc/passwd fájlokat az összes 

olyan gépről, mely az új NIS-tartomány része lesz. Távolít- 
suk el belőlük a rendszerfiókokat, majd az összes fájlt má- 
soljuk egybe: 


7 cat jelszo 1 jelszo 2 jelszo 3 ... : 
s osszegyujtott jelszavak 


Az alábbi paranccsal távolítsuk el a kettős bejegyzéseket: 


7 sort osszegyujtott jelszavak ] unig - 
s egyedi jelszavak 


Ellenőrizzük a fennmaradt bejegyzések egységességét: 


7 cut -d":" -fl egyedi jelszavak ] sort I] unig -c 
et [A 


egrep -v NVsFr1" 


Ha a parancs bármit is ad kimenetként, akkor van két külön- 
böző, de azonos fióknévvel rendelkező bejegyzésünk. Ha az 
eltérés nem az UID vagy a GID mezőben jelentkezik, akkor 
egyszerűen válasszuk ki az egyik bejegyzést, és töröljük a má- 
sikat. Ha az UID vagy a GID mező tér el, akkor fel kell olda- 
nunk az ütközést, ami akár egészen bonyolult feladat is lehet. 
Végezzünk újabb ellenőrzést; van-e két azonos LIID-vel 
rendelkező fiók? 

Ha a: 


7 cut -d":" -f3 egyedi jelszavak ] sort ] unig -c 
se N 


egrep -v NVsFr1" 


parancs bármilyen kimenetet is ad, akkor igen. A második 
kapott szám a kettős LIID. Az ütközés feloldása ebben az 
esetben is fárasztó feladat lehet. Hasonló módon az összes 
/etc/group fájlt is egyesítenünk kell. 

A kapott fájlokat másoljuk a /etc/NIS/passwd és 

a /etc/NIS/group elérési út alá. A netgroup fájlt egyelőre 
hagyjuk ki, majd később foglalkozunk vele. 

Indítsuk el a mester NIS-kiszolgálót: 


$ service ypserv start 
A NIS-térképeket az alábbi paranccsal: 
$ /usr/1Vib/yp/ypinit -m 


illetve a megjelenő utasításokat követve vehetjük hasz- 
nálatba. 

Ha a mester NIS-kiszolgáló számára az összes NIS-térképet 
elérhetővé akarjuk tenni, akkor ezt a gépet NIS-ügyfélnek 
is be kell állítanunk. Ellenőrizzük, hogy ez a NIS-ügyfél 
csak a mester NIS-kiszolgálóhoz tud-e kötni, ezzel megelőz- 
hetjük, hogy például egy áramkimaradás után az induló 
gépek között körkörös függés alakuljon ki. 
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A szolya kiszolgáló beállítása 

A szolga NIS-kiszolgálók olyan NIS-ügyfelek, melyek 

a mester NIS-kiszolgálótól kapott térképeket továbbterjesz- 
tik a többi NIS-ügyfél felé. Ellenőrizzük, hogy a legújabb 
portmap, ypserv, ypbind és yp-tools RPM-ek az összes 
szolga kiszolgáló gépre telepítve vannak-e. Egy szolga 
NIiSkiszolgáló üzembe helyezésének első lépése az, hogy 
NIS-ügyfélként állítjuk be. Ennek módjáról a következő 
részben lesz szó. 


Ha a NIS-ügyfél beállítása megtörtént, indítsuk el: 
ff service ypbind start 


A mester NIS-kiszolgálón adjuk hozzá az új szolga NIS- 
kiszolgáló nevét a /var/yp/ypservers fájlhoz, majd futtassuk 
le az alábbi parancsokat: 


ff cd /var/yp 
ft /usr/Vib/yp/makedbm ypservers 
/var/yp/nis. example . com/ypservers 


A mester NIS-kiszolgálón a /etc/YP/Makefile fájlban 

a NOPUSH megadást is meg kell változtatnunk, true ér- 
tékről false-ra, a frissített NIS-térképek ugyanis csak 
ekkor kerülnek át a mester kiszolgálóról a szolgára vagy 
szolgákra. 

Visszatérve az új szolga NIS-kiszolgálóra, elindításához 

a következő parancsot kell kiadnunk: 


ít /usr/1ib/yp/ypinit -s nismester 


Itt a nismester a mester NIS-kiszolgáló neve. Ennek egy 
teljesen minősített tartománynévnek kel lennie, feltéve, 
hogy DNS-kiszolgálónk a névkeresésekre ilyet ad vissza. 
A mester NIS-kiszolgálóról másoljuk a /var/yp/securenets 
fájlt az új szolga kiszolgálóra, majd az alábbi paranccsal 
indítsuk el az új szolgát: 


4 service ypserv start 


A katasztrófa utáni helyreállítás tervét ne felejtsük el frissí- 
teni, és jelezzük benne, hogy a szolga NIS-kiszolgáló függ 
a mester NIS-kiszolgálótól. 


Az ügyfelek beállítása 

Az összes ügyfélre telepítsük a legújabb ypbind, yp-tools 
és portmap RPM-eket. A /etc/yp.conf fájlt írjuk át; adjuk 
meg benne a NIS-kiszolgálót: 


ypserver nismester .pelda. com 


A szolga kiszolgálókat külön-külön sorokban kell megad- 
nunk. Az ügyfeleken próbáljuk véletlenszerűen felsorolni 
a kiszolgálókat, így a terhelést viszonylag egyenletesen 
tudjuk elosztani közöttük. 

A /etc/sysconfig/network fájlhoz az alábbi sort írva adjuk 
meg az ügyfél NIS-tartományát: 


NISDOMAIN-nis . pelda. com 
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Állítsuk be a NIS-tartománynevet: 
ff domainname nis.pelda. com 
Indítsuk el a portmappert: 

f$ service portmap start 
illetve a NIS-ügyfelet: 

$ service ypbind start 


az összes ügyfélen. 

Az ypwhich parancsnak most azt a NIS-kiszolgálót kell 
kiírnia, amelyhez az ügyfél kötődik. 

A NIS-térképek tartalmát az ypcat paranccsal tudjuk 
megvizsgálni. Például: 


96 ypcat passwd 


Következő teendőnk az, hogy az ügyfeleket úgy állítsuk 
be, hogy minden keresést NIS segítségével végezzenek. 
Ezt a névszolgáltatás-kapcsoló /etc/nsswitch.conf beállító 
fájljának módosításával érhetjük el. A passwd, a group 
és a netgroup bejegyzéseket a következőképpen kell 
módosítanunk: 


passwd: compat 
group: files nis 
netgroup: nis 


A fentiek értelmében a csoport (group) kereséseket a helyi 
/etc/group fájllal kell kezdeni, majd egy NIS-kereséssel kell 
folytatni. A hálózati csoportokat (netgroup) kizárólag NIS 
alatt kell keresni. A passwd mögött álló compat kulcsszóról 
később ejtünk szót. 

Megjegyezném, hogy az nscd névszolgáltatás-gyorsítótá- 
razó (name service caching) démonnak időnként gondjai 
vannak belső gyorsítótárának frissítésével. Ennek hatása- 
ként előfordulhat, hogy a valamelyik NIS-térképben vég- 
rehajtott módosítások egy-egy ügyfélen nem látszanak. 
Ilyenkor az egyetlen megoldás az adott gép nscd-jének 
újraindítása. 


Jellemző felhasználások 

Ha NIS alól információkat akarunk lekérdezni, akkor két 
paranccsal mindenképpen érdemes megismerkednünk; az 
egyik az ypcat, a másik az ypmatch. Az ypcat végigmegy az 
adott NIS-térkép összes kulcsán, és kiírja a benne szereplő 
értéket. Például az ypcat passwd paranccsal a passwd NIS- 
térkép bejegyzéseit listázhatjuk ki. Az ypmatch a megadott 
NIS-térképből egy vagy több kulcs értékét írja ki; az 
ypmatch julia passwd parancs például a julia nevű fiók 
passwd bejegyzését adja meg. 


NIS csoporttérkép 

A NIS csoporttérkép jellegzetes használata a több felhasz- 
náló közötti fájlmegosztás lehetővé tétele. A megoldás helyi 
és NFS-en található fájlokkal egyaránt működik. Lássuk 

a beállításokat. Tegyük fel, van két felhasználónk (az eljárás 
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tetszőleges számú felhasználóval is működik), ők a követke- 
ző bejegyzésekkel rendelkeznek a passwd térképben: 


julia:":1234:42:Julia:/home/julia:/bin/bash 
janos:":5678: 57: Janos : /home/janos : /bin/bash 


A fentiek értelmében az elsődleges csoportazonosító julia 
esetében 42, janos-nál pedig 57. 

A NIS csoporttérképpel egy további, másodlagos csoport- 
tagságot is megadhatunk a fiókokhoz. A 


tervezetx:":127:julia, janos 


csoportbejegyzés egy új, tervezetx nevű csoportot ad meg, 
jelszó nélkül ("), 127-es csoportazonosítóval és két taggal. 

A csoportfájlban nem lehetnek megjegyzések. 

Ha most egy könyvtárra olvasási/írási/tuttatási jogot adunk 
a tervezetXx csoportnak: 


$ mkdir /tervezetek/X/ 
tf chgrp tervezetX /tervezetek/X/ 
ff chmod giwrx /tervezetek/Xx/ 


akkor a tervezetx csoport minden tagja olvasási/írási/futta- 
tási jogot kap a könyvtár fájljaira. Lehetséges, hogy a felhasz- 
nálónak először ki kell adnia a newgrp tervezetx parancsot. 
Ha hozzá kell adnunk egy fiókot egy csoporttérképhez, 
illetve, ha el kell távolítanunk belőle ilyet, akkor azt 

a mester NIS-kiszolgálón, a /etc/NIS/group fájl módosításá- 
val és a következő parancsok kiadásával tegyük meg: 


7 cd /var/yp 
7. sudo make group 


Ekkor létrejön az új csoporttérkép, amelynek révén az 
összes ügyfél azonnal láthatja a változásokat. A módosítás 
elvégzéséhez az ügyfelek közelébe sem kell menni -— hiszen 
minden központosítva van egy helyre, a NIS-kiszolgálóra. 


NIS hálózati csoportok 

A hálózati csoportok (netgroup) teljesen eltérők a csoportok- 
tól. A hálózati csoportok két típusra oszthatók, felhasználói 
és állomás hálózati csoportokra. Mindkét típusú hálózati 
csoport további hálózati csoportokat is tartalmazhat tag- 
ként, vagyis a hálózati csoportok hierarchiába rendezhetők. 
Mindkét típus megadása ugyanabban a netgroup fájlban 
történik. Ebben a fájlban megjegyzések is lehetnek. 

A /etc/NIS/netgroup fájl állomás hálózati csoport megadásai 
így néznek ki: 


f Tervezetcsoportok csoportja: 
tervezetek N 
tervezetáA N 
tervezetB N 
tervezetXx 
tf Az X tervezet állomáscsoportja 
tervezetXk N 
(allomas1. pelda. com, -,) NM 
(allomas2 . pelda. com, -, d) N 
(allomas3. pelda. com, - , ) 








A fenti állomás hálózati csoportok révén lehetővé válik, 
hogy például egy NFS tárterületet csak a munkaállomások 
egy részéről lehessen elérni. NES kiszolgálónk /etc/exports 
fájljában például a következő elérhetőségeket írhatjuk elő: 


$ a /tervezetek könyvtár elérhetővé tétele az 
f$ összes olyan gép számára, 

$ amely a "tervezetek" hálózati csoportban 

ft található 

/tervezetek Etervezetek(rw, root. sguash) 

f a "tervezet X" csak azokról a gépekről 

ft érhető el, amelyek a "tervezetx" 

$ hálózati csoport 
f$f tagjai 
/tervezetek/Xx GtervezetX(rw, root sguash) 
Az állomások hozzáadása a hálózati csoportokhoz, illetve 
kivétele belőlük az előbbihez hasonló módon a mester NIS- 
kiszolgálón található /etc/NIS/netgroup fájl átírásával végez- 
hető el. A NIS-térképet a cd /var/yp; sudo make netgroup 
parancsokkal frissíthetjük. A változások mindenhol azonnal 
megjelennek. 


Felhasználói hálózati csoportok 

A felhasználói hálózati csoportoknak felhasználók a tag- 
jai, szerepük elsősorban az egyes számítógépekre való 
bejelentkezések korlátozására terjed ki. A felhasználói há- 
lózati csoportok megadása kicsit eltér az állomás hálózati 
csoportokétól: 


ft Tervezet felhasználói csoportok csoportja 
u-tervezetek NM 

u-tervezetAáA N 

u-tervezetB N 

u-tervezetx 


tf Az X tervezet felhasználócsoportja 
u-tervezetX N 

(C-, julia, 9. N 

(- , janos, 9). NA 

(- , norbert,) 


A felhasználói (user) hálózati csoportokat hagyományosan 
az u- előtaggal különböztetik meg az állomás hálózati cso- 
portoktól. 

A fenti definíciók birtokában a gépek helyi /etc/passwd 
fájljában lévő, hasonló típusú bejegyzésekkel tudjuk 
engedélyezni vagy éppen tiltani a bejelentkezést az egyes 
gépekre. A passwd fájlok legvégéről vegyük ki a -- jelet, 
ha van ilyen: 


A hozzáférés az u-tervezetek hálózati csoportban lévő 
fiókokra történő korlátozása: 


1du-tervezetek 


A hozzáférés korlátozása az u-tervezetXx hálózati 
csoport tagjaira: 


4du-tervezetx 
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Hozzáférés biztosítása azoknak, akik az u-ter- 
vezetek csoportnak tagjai, de az u-tervezetx 
csoportnak nem: 


-(u-tervezetx 
-(0u-tervezetek 


Ez esetben fontos a sorrend. Mindig az első egyezés szabja 
meg, hogy mi történik. 


Engedély megadása az u-tervezetA csoport tagjainak 
és a norbert fióknak: 


4(du-tervezetA 
Hnorbert 


A norbert fiókkal kapcsolatos adatok (kezdőkönyvtár, 
bejelentkezési héj stb.) a NIS passwd térképből szár- 
maznak. Kifejezett fiókneveket ide inkább ne helyez- 
zünk, mert ezeknek a bejegyzéseknek a kezelése nincs 
központosítva. 

A 4/- jelekre alapuló írásmód működéséhez az ügy- 
felek /etc/nsswitch.conf fájljába a következő sort kell 
beilleszteni: 
passwd: compat 

Osszefoglalás 

Ha a NIS-kiszolgáló telepítésének és a jogosultság-kezelési 
adatok egységesítésének gondján-baján túlestünk, a köz- 
pontosítással könnyebbé válik az életünk. A hálózati cso- 
portok révén összetett, kifinomult, központi hozzáférés- 
vezérlést valósíthatunk meg. 


Linux Journal 2005. március, 131. szám 








Dr. Alf Wachsmann 

1999 óta a Stanford Linear Accelerator 
Center (SLAC) munkatársa. Ő felelős az 
önműködő Linux-telepítések minden moz- 
zanatáért, egyaránt ide értve a farmok 
csomópontjainak, a kiszolgálóknak és 

az asztali gépeknek a kezelését. Munkája 
során elsősorban az aktív fájlkészletek 
(AFS) támogatásával, a Kerberos 5-re 

való áttéréssel, egy felhasználónyilvántartó 
tervezettel és felhasználói tanácsadással 
foglalkozik. 


2 www.tldp.org/HOWTO/NIS-HOVVTO/ 
index.html 


2 www.padl.com/oss/Migration Tools.html 
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Az OSCAR és a bioinformatika 


Az új fürt-telepítő és -irányító eszközökkel egy óra alatt létrehozhatunk és a kuta- 
tómunkánk szolgálatába állíthatunk egy 64 csomópontos számítógépfürtöt. 


z OSCAR (Open Source Cluster Applications 
A Resources) nyílt forrású fürtöző programkészlet) 

projekt körülbelül négy éve indult. Az elv 2000 
januárjában került először előterjesztésre, az első szervezeti 
találkozóra pedig ugyanez év áprilisában került sor. A cso- 
port felismerte, hogy a fürtök összeállítása meglehetősen 
időrabló és rutinszerűen ismétlődő tevékenység, ezért 
a projekt céljául ennek a folyamatnak az önműködővé téte- 
lét tűztük ki. A csoport azt remélte, hogy ennek hatására 
szélesebb körben terjed majd el a fürtök használata, és al- 
kalmassá válik a tudományos életben és a magánszektorban 
való alkalmazásra is. 
Az OSCAR projektet a nyílt tagsággal rendelkező nem 
hivatalos testület, az OCG (Open Cluster Group) tanács- 
adó csoport felügyeli. Az OCG azért küzd, hogy növelje 
a fürtözés alkalmazhatóságát a nagyteljesítményű számí- 
tások (HPC, high-performance computing) kutatásának 
és fejlesztésének területén. A csoport — az OSCAR pro- 
jekthez hasonlóan - a tudományos élet és az ipar je- 
les képviselőinek az irányítása alatt áll. Legfontosabb 
tagjai közt találjuk a következő intézményeket: Bald 
Guy Software, BC Genome Tudományos Központ, Dell, 
Indiana Egyetem, Intel, Louisiana Műszaki Egyetem, 
Oak Ridge Nemzeti Labotartórium, Revolution Linux 
és a Sherbrooke Egyetem. 
Az OSCAR-csoport az OCG egyik munkacsoportja. Emellett 
további projektek is működnek, így a HA-OSCAR (high- 
availability, magas rendelkezésre állású), Thin-OSCAR 
(lemez nélküli) és SSS-OSCAR (skálázható). Az OCG-ről 
további információkat a cikkhez tartozó, a világhálón elér- 
hető hivatkozások közt találhatunk. 
Az OSCAR legelőször 2001 áprilisában jelent meg, azóta két 
fő változatot bocsátottunk ki. A kibocsátási ciklus rendsze- 
rint egybeesik az évente novemberben megrendezésre ke- 
rülő SuperComputing konferenciával. Az írás idején aktuális 
változat a 3.0, amit a SuperComputing04-re tervezett 4.0 vál- 
tozat kibocsátása követne. 
Az OSCAR célja, hogy a HPC-fürtök telepítésének, progra- 
mozásának és karbantartásának lehető legjobb eszközét 
nyújtsa a felhasználók számára. Sok olyan nyílt forrású 
összetevőt találunk, amely jól működik egy HPC-környe- 
zetben, de ehhez szükség van a megfelelő beállítások elvég- 
zésére. Az OSCAR jelenti az összekötő anyagot ezeknek az 
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összetevőknek egy jól működő eszközkészletté történő 
egyesítéséhez. A projekt a közepes méretű (50 és afeletti 
csomópontokbál álló) fürtöket célozza meg, mivel a vissza- 
jelzések alapján a manapság használt fürtök többsége ebbe 
a méretkategóriába esik. 

A OSCAR a következő összetevőkből épül fel: 


Rendszerfelügyelet: System Installation Suite (SIS, 
rendszertelepítő csomag) , Cluster Command and Control 
(C3, fürtvezérlő parancsfelület) és az OPIUM (felhasz- 
nálókezelő). 

HPC-eszközök: párhuzamos programozói könyvtárak: 
MPICH, LAM/MFPI és a PVM; kötegelő rendszerek: 
OpenPBS/MAUIL, Torgue és az SGE; megfigyelő eszkö- 
zök: Ganglia és Clumon; és egyéb külső fejlesztésű 
OSCAR-csomagok. 

Alapinfrastruktúralirányítás: OSCAR Database (ODA, 
OSCAR adatbázis) és az OSCAR Package Downloader 
(OPD, OSCAR csomagletöltő) . 


Az OSCAR fejlesztői egymástól távol dolgoznak, az ak- 
tuális fejlesztési kérdéseket heti telefonkonferenciákon 
vitatják meg. A csoport ezen kívül évente rendez olyan 
találkozókat, ahol a jövőbeli változatokba kerülő új tulaj- 
donságokat találják ki és beszélik meg. Évente egy tudo- 
mányos tanácskozás is megrendezésre kerül, rendszerint 
a HPCS (a nagyteljesítményű számítási rendszerek és 
alkalmazások nemzetközi tudományos tanácskozása) 
keretein belül, amelyen a felhasználók adhatják elő az 
OSCAR-ral kapcsolatos tapasztalataikat és a HPC-vel kap- 
csolatos fejlesztési eredményeiket. A második OSCAR 
Symposium 2004 májusában, a kanadai Winnipegben ke- 
rült megrendezésre, az itt készült anyagok bárki számára 
hozzáférhetőek. 


Bevezetés a bioinformatikába 

A bioinformatika a biológia és a számítástudomány egyesü- 
léséből keletkezett, gyorsan fejlődő tudományterület, amely 
nagy lehetőségeket hordoz a HPC területe számára. Egysze- 
rűen megfogalmazva a bioinformatika az olyan biológiai 
adatok számítógépes eljárásokkal és rendszerekkel történő 
feldolgozásával foglalkozik, mint a DNS, RNS, a fehérjék és 
egyéb szabályozó alkotóelemek. 








OSCAR installation Wizard 












Welcome to the OSCAR wizard! 





Step 0: 


Step 1: Select OSCAR Packages To install...) Help... ) 
Step 2: Configure Selected OSCAR Packages... l Help... I 
Step 3: install OSCAR Server Packages —— ) Help... 
Step 4: Build OSCAR Cent Image... ! Help -] 























1. kép Az OSCAR telepítésének főmenüje. Kevesebb, mint tíz lépés, 
és a fürt készen áll a számítások megkezdésére! 


A biológiai adatok rendszerint karaktersorozatok, amelyek 
elemzése rendszerint karakterlánc-műveleteket jelent, ezért 
a legtöbb bioinformatikus munkaeszközéül a Perl nyelvet 
választotta. Sok nyílt forrású Perl programot író programo- 
zó járul hozzá a Bioperl kifejlesztéséhez, amely a bioinfor- 
matikai elemzésekre specializálódott PerI-modulok gyűjte- 
ménye. A Java nyelvet nagyobb, főleg grafikai felületet is 
igénylő projektekhez használják. Megfigyelhető még a te- 
rületen a Python térnyerése is, ahogy egyre több programo- 
zó fedezi fel ennek a viszonylag új, de nagyon hatékony 
nyelvnek a könnyű használhatóságát és jó olvashatóságát. 
A bioinformatikus közösségben nagyon elterjedt a Linux 
fürtök használata, mivel az elemzések egyre hosszabb ideig 
futnak és gyakran ismétlődő feladatokat jelentenek. 

A Linux fürtök ideális eszközt jelentenek az ilyen egymástól 
függetlenül futtatható, párhuzamos feladatok végrehajtásá- 
ra. Ezek nem tekinthetők igazi párhuzamos programoknak, 
mivel nincs szükségük az MPI-hoz hasonló párhuzamos 
programozói könyvtárakra. A bioinformatika elterjedt 
eszközét az olyan fürtök jelentik, melyek több parancsfájlt 
és algoritmus futtatnak különböző bemenetekkel, külön 
címzési tartománnyal rendelkező processzorokon. 


Egy jellemző OSCAR-telepítés áttekintése 

Egy fürt telepítése az OSCAR eszközkészlettel egyszerű 
folyamat, ha telepítettünk korábban Linuxot, nem sok 
gondunk adódhat. 
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NCSA OSCAR package reposítory 


ganglia third-party 2.5.6-1 NCSA OSCAR package reposítory 
Maui third-party 3.2.5p7-2 NCSA OSCAR package repository 
mpich-gm third-party 1.2.54 NCSA OSCAR package repository 
MPICH-VMI third-party 2.0.b3p1-1 NCSA OSCAR package repository 
Myrinet Driver (GM) . third-party 2.0.9-1 NCSA OSCAR package reposítory 
PVFS third-party 1.6.0-3 NCSA OSCAR package repository 
thin-OSCAR DÁK aA thin-OSCAR páckága Kán zi 











2. kép Az OSCAR Package Downloader (csomagletöltő) 
— ebben a menüpontban van lehetőségünk 
további csomagok letöltésére 


Jelenleg az OSCAR három hivatalosan támogatott Linux 
rendszercsomagra telepíthető: Red Hat 8.0, Red Hat 9.0 és 
Mandrake 9.0. A Linux telepítésnek tartalmaznia kell vala- 
milyen X ablakrendszert, amilyen a KDE vagy a GNOME, 
ettől eltekintve egy tipikus, programfejlesztő eszközök- 

kel telepített munkaállomás beállításainak megfelelőnek 
kell lennie. 

Miután feltelepítettük és beállítottuk a Linuxot a központi 
csomópont gépén, letölthetjük az OSCAR tar-csomagját 

a projekt honlapjáról és a kicsomagolás után elvégezhetjük 
a beállító, make és make instal1 lépéseket. 
Alapértelmezésben az OSCAR telepítése az /opt/oscar 
könyvtárba történik, de ezt a configure parancs -prefix 
beállításával megváltoztathatjuk. Az OSCAR telepítését 
követően elindíthatjuk az OSCAR varázslót, amely lépésről 
lépésre végigvezet a fürtünk beállításán. 

A varázsló indításához lépjünk be az /opt/oscar könyvtárba 
majd gépeljük be az 


./install. cluster ethXx 


parancsot, ahol az ethx a fürt hálózatának felületét jelenti. 
Az OSCAR számos előre összeállított csomaggal érkezik. 

A más gyűjteményből származó csomagok is érdeklődésre 
tarthatnak számot. Ezek letöltéséhez kattintsunk az OSCAR 
varázsló Download Additional OSCAR Packages (további 
OSCAR-csomagok letöltése) feliratú gombra és válasszuk 

ki a csomago(ka)t. 

Ezután kiválaszthatjuk a telepíteni kívánt OSCAR-csoma- 
gokat. A csomagok három fő csoportba sorolhatók: közpon- 
ti csomagok, tartozék-csomagok és külső fejlesztésű csoma- 
gok. A központi csomagokat mindenképpen telepítenünk 
kell, ezek kijelölését nem tudjuk törölni. A tartozék-csoma- 
gok azok, amelyeket az OSCAR fejlesztőcsapata telepítésre 
javasol, a maradékot pedig a külső forrásokból származó 
csomagok alkotják. 

A csomagok beállításait a Configure Selected OSCAR 
Packages (a kiválasztott OSCAR-csomagok beállításai) 
menüben változtathatjuk meg. 
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W rootgoscarjoptjoscar 7-5 Xt 
File Edit View  Ierminal Go Help 
Adding path entries to /etc/profile E 


--s Updating /etc/exports 

Backing up /etc/exports 

Checking for /home export 

Found /home entry 

Existing /home entry ok, preserved 

--3 Updating rsyncd.conf 

Backing up rsyncd header stub 

Found hosts allow stanza 

Looks like we alread have it! 

Updated rsyncd.conf file 

--s Refreshing services 

Starting NFS services: 

Starting NFS guotas: 

Starting NFS daemon: 

Starting NFS mountd: 

Starting sshd: 

--s Fixing root "dot" files 

Making any necessary PATH fixes to (/root/.bashrc) 
Making any necessary PATH fixes to (/root/.tcshrc) 
Making any necessary PATH fixes to (/root/.cshrc) 





OK 
OK 


[ 1 
[ 1 
(I ox ] 
[ 1 
[ 1 


OK 








--s Step 3: Successfully installed OSCAR server 


--s Finished server. prep script 1] 


hd Create a System Installation Suite Image 


Fill out the following fields to build a System Installation 
Suite image. If you need help on any field, click the help 
button next to it 


mantamk ÍME Help) 


Package File: [/opVoscarroscarsamples/ Choose a File... Help ] 
Packages Directory: bootrrpm Help ] 


Disk Partition File: [/do/oscarfoscarsamples/ . Choose a File...) Help ) 
IP Assignment Method: static ] — Help ] 


off sa 





Multicasting: ] — Help ] 
Post install Action: beep -] — Help ) 
Reset Build Image ose 











3. kép Egy beavatkozást nem igénylő lépés: 
a kiszolgáló csomagjainak telepítése 


A következő lépés az OSCAR kiszolgáló csomagjainak 
(Server Packages) telepítése. Ez alapvetően a kiszolgálón 
használt csomagok telepítésére szolgál, és nem igényel fel- 
használói beavatkozást. A telepítés befejezéséről egy ablak 
megjelenése tájékoztat. 

Most következik az érdekes rész. A Build OSCAR Client 
Image lépéssel létrehozhatunk egy ügyfél-képfájlt. Itt beál- 
líthatunk néhány lehetőséget a létrehozandó képfájl számá- 
ra, majd feltölthetjük a képfájlt az ügyfélcsomópontokra. 
Megadhatjuk az alapképfájl RPM-csomagjainka listáját, 
eldönthetjük, hogyan legyen a merevlemez partícionálva, 
és elvégezhetjük az IP-cím hozzárendelését. Végül kivá- 
laszthatjuk a képfájl áthelyezését követő műveletet, példá- 
ul a gép újraindítását. 

A Define OSCAR Clients (az OSCAR-ügyfelek megadása) 
lépésben megadhatjuk a tartománynevet, az ügyfél nevét, 
a munkafolyamathoz használandó csomópontok számát és 
egyéb hálózati beállításokat. Az Add clients feliratú gombra 
kattintva érvényesítjük a beállításokat és már majdnem 
kész is a fürt. 

A következő lépés a fürt hálózatának üzembe helyezése. 
Itt indíthatjuk el az ügyfélcsomópontokon a rendszert 

a PXE vagy floppy segítségével, majd az OSCAR központi 
csomópontja összegyűjti a MAC-címeket, amiket a konkrét 
gépekhez rendelhetünk. Ezután rögtön megtörténik az 
ügyfélgépek képfájljainak üzembe helyezése. A merevle- 
mez sebességétől függően ez gépenként 10-30 percet ve- 
het igénybe. Egy fürt üzembe helyezésekor egyszerre több 
csomóponton is folyhat ez a művelet. Mi rendszerint 10 
gépen indítjuk el párhuzamosan, hogy elkerüljük a köz- 
ponti csomópont túlterhelését. Ezzel a fokozatos eljárással 
egy 64-csomópontos fürt üzembe helyezése nem tarthat 
tovább egy óránál. 

A csomópontok képfájljainak felhelyezése és a gépek újra- 
indítása után folytathatjuk a következő lépéssel, amely 

A fürt beállításainak befejezése (Complete the Cluster Setup). 
Ez megint nem igényel felhasználói beavatkozást, ekkor 
hajtódnak végre a végső telepítési műveletek és egyéb tisz- 
tító folyamatok. 

Végül nem árt ellenőrizni a fürt beállításait a Test Cluster 
Setup lépéssel. Ez egy tesztsorozatot futtat le a fürt telepíté- 
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4. kép Ügyfél-képfájl létrehozása a felhasználó által megadott 
csomaglista és partíciós tábla alapján 


sének és a független csomagok ellenőrzésére. Ha minden 
jól megy, akkor a tesztek sikeresek lesznek, az üzembe he- 
lyezés befejeződött, a fürt készen áll a számítási feladatok 
végrehajtására. 

Az OSCAR eszközkészlet telepítése egyszerű és általában 
minden hardveren működik. Ha mégis valamilyen prob- 
lémával találkoznánk, a levelezőlistákon kérhetünk segít- 
séget. A kérdéseket első körben az oscar-users listához 
intézhetjük. A központi csapat nagy része rendszeresen 
olvassa a listát és a többi felhasználó is a segítségünkre 
lehet. Ha a fejlesztéssel kapcsolatos kérdés merülne fel, 
erre az esetre az oscar-devel lista áll rendelkezésünkre. 
Mindkettő lista zárt, fel kell iratkoznunk, mielőtt üzenetet 
küldhetnénk rájuk. 


Az OSCAR 4.0 újdonságai 

Sok újdonságot tervezünk beépíteni a hamarosan 
megjelenő új változatba, amelyek négy csoportra 
oszthatók: NEST, csomópont-csoportok, Linux rend- 
szercsomagok és SIS. 

A NEST (Node Event and Synchronization Tools, csomó- 
pont esemény és szinkronizáló eszközök) azt biztosítja, 
hogy a fürt minden csomópontjának beállításai szinkron- 
ban legyenek a központilag tárolt adatokkal. Jelenleg új 
fürt-csomópont telepítésekor az OSCAR post. install 
parancsfájljait minden csomóponton le kell futtatni füg- 
getlenül attól, hogy erre ténylegesen szükség van-e. 

Bár ez a modell a közepes méretű fürtökön működőképes, 
nyilvánvalóan egy méretbeli korlátozást jelent. A legna- 
gyobb eltérés a NEST-ben, hogy a csomag-beállítások 

a kiszolgálóról töltődnek le, ahelyett, hogy az ügyfelekre 
töltődnének fel. A műveletek csak szükség esetén hajtód- 
nak végre, ami sokkal elegánsabb megoldás a jelenleg 
alkalmazott feltétel nélküli végrehajtási sémánál. 

A csomópont-csoportok a fürtben lévő csomópontok tet- 
szőleges csoportosítását jelentik. Ezzel az új szolgáltatással 
lehetővé válik az OSCAR-csomagok csoportonként eltérő 
kezelése. A következő változatban csak a kiszolgáló- és 
ügyfélcsomópont-csoportokat tervezzük támogatni, de 

a jövőben a felhasználóknak lehetőségük nyílik majd saját 
csoportok létrehozására is. 








hadl Add Clients to 


a SIs ante. őt 


5. kép Itt adhatjuk meg a fürt csomópontjait és a hálózati jellemzőket 


Ív MAC Address Collection a BX 


MAC Address Collection Tool. When a new MAC address is received on the 
EAT t ke E ee To assign that MAC address to a 
machine highlight the address and the machine and click "Assign MAC to Mode". 


Not Listeniny to Network. Click "Collect MAC Addresses" to start. 


ip - 192.168.22.11 

E-oscamode02.oscardomain 
mac - 00:09:6b:00:c4: 

th0 ip - 192.168.22.12 





Below are commands to create a boot environment. 
You can either boot from floppy or network 


. ) Setup Network Boot! W Dynamic DHCP update 








6. kép A fürt csomópontjain megtörtént a hálózatos rendszerindítás 
és a MAC-címek gépekhez rendelése 


Az OSCAR meghatározó jellemzője a különböző Linux 
rendszercsomagok támogatása. Az új változattal reménye- 
ink szerint megvalósul a Fedora Core 2 és 3, a Red Hat 
Enterprise Server 3.0 és a Mandrake 10 támogatása. Ezzel 
együtt támogatni fogjuk az IA-64 és x86-64 rendszereket is. 
A System Installation Suite (SIS, rendszertelepítő csomag) 
amely magába foglalja a Systemlmager-t is, az OSCAR kép- 
fájljait üzembe helyező programcsomag. Két továbbfejlesz- 
tés sorolható ide. Az egyik a lemeztípus önműködő észlelé- 
se. Hagyományosan az OSCAR képfájlok egyféle merevle- 
mez-típusra készültek (vagy IDE vagy SCSI). Ezzel az 
OSCAR-kiterjesztéssel ugyanazt a képfájlt használhatjuk 

a különböző felépítésű és merevlemezzel rendelkező gé- 
pekhez feltéve, hogy a gép központi felépítése megegyezik. 
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Másodszor, hozzáférhető egy eszköz, amivel a felhasználók 
speciális rendszermag-modulokat használhatnak a csomó- 
pontok rendszerindításához. Időnként előfordul, hogy az 
újabb hardvereken nehezebb munkára bírni az OSCAR-t, 
mivel a SIS rendszermag-indító képfájl nem tartalmazza 

a támogatott meghajtóprogramokat. Ennek az eszköznek 
a segítségével használhatjuk a meglévő rendszermagot 

a biztosan működő modulokkal, és így az ügyfélcsomó- 
pontjainkra feltölthető a képfájl. Ez a szolgáltatás részét 
fogja képezni a Systemlmager következő változatának és 
reményeink szerint az OSCAR 4.0 verziónak is. 


Csomagok létrehozása az OSCAR számára 

Az OSCAR rendelkezik a megfelelő csomagokkal az általá- 
nosan használt, fürtözött környezetre felkészített progra- 
mokhoz. Ezek egyszerű RPM-csomagok a megfelelő 
metafájlokkal és telepítő parancsfájlokkal, amelyeket az 
OSCAR elsődleges fejlesztőcsapata és a csomagírók készíte- 
nek és tartanak karban. Ha van egy olyan programunk, 
amelyet telepíteni szeretnénk a fürtre de az OPD-n 
(OSCAR Package Downloader, OSCAR csomagletöltő) ke- 
resztül nem találjuk, készítsünk hozzá egy csomagot. Az 
OSCAR fejlesztőcsapata nyitott a közreműködni szándéko- 
zók felé, és esetleg az általunk készített OSCAR-csomagnak 
is hajlandó helyet biztosítani. A csoport ezt a meghívást 

a programfejlesztőkre is fenntartja. 

Az OSCAR-csomagok olyan decentralizált webhelyeken 
elhelyezkedő csomag-gyűjteményekben foglalnak helyet, 
amelyeket a csomagok szerzői biztosítanak a csomagok 
fájljainak tárolására. A tárhelyek címei egy központi 
tárhelylistán érhetőek el. 

Az OSCAR-csomagok létrehozása általában egyszerű folya- 
mat. Ha rendelkezésünkre áll egy kész RPM-csomag, a fel- 
adat felével már nem is kell foglalkoznunk, mindössze 

a csomag és RPM-fájlok metaadatait tartalmazó fájlokat kell 
létrehoznunk és néhány olyan parancsfájlt, amely gondos- 
kodik a beállításokat tartalmazó fájlok terítésével a fürtön 
belül. A feladat végrehajtása viszonylag egyszerű, mert egy 
OSCAR-türtön belül sok feltétel már eleve adottnak vehető. 
Amennyiben nem áll rendelkezésre megfelelő RPM- 
csomag, a folytatás előtt magunknak kell létrehoznunk 
az alkalmazás RPM formátumú alakját. Az RPM-csomag 
létrehozása a program összetettségétől függően lehet 
könnyű, de bonyolult is. Készítenünk kell egy leírófájlt 
és létre kell hoznunk az RPM fájl(oka)t és a hozzá tarto- 
zó SRPM forráscsomagot. 

A GSC (Genome Sciences Centre, Génkutató Központ) ál- 
tal kiadott eső OSCAR-csomag a Ganglia csomagja volt, 
amely egy fürtmonitorozó rendszer. Már dolgozunk 

a második csomagunkon, amely a Sun Grid Engine nevű, 
a Sun Microsystems által támogatott nyílt forrású parancs- 
fájl-ütemező rendszer. Ez a későbbiekben elérhető lesz 
majd az OSCAR letöltő rendszerén keresztül a GSC 
OSCAR tárhelyén. 


Bioinformatikai alkalmazások és az OSCAR-fürt 

A legelterjedtebben használt bioinformatikai program a ge- 
netikai kódsorok keresésére és illesztésére használt BLAST. 
A genetikai adatbázisban több genetikai kódsor keresése jól 
párhuzamosítható feladat, a folyamat nagyon könnyen 
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w rootgoscarz/warjlibjsystemimagerfimagesjoscarimagejetc/sysconfig/network-scripts 


File Edit Miew  Ierminal Go Help 

Shutting down kernel logger: [/ 0K ] ké 
Shutting down system logger: [/ 0K ] 

Starting system lögger: [/ 0K )] 

Starting kernel logger: ([ OK )] 

--s About to run /var/lib/oscar/packages/ganglia/scripts/post. install for gangli 

a 

building file list ... 
gmond. conf 

building file list ... 
gmond. conf 

wrote 792 bytes read 72 bytes 1728.00 bytes/sec 
total size is 3709 speedup is 4.29 

wrote 792 bytes read 72 bytes 576.00 bytes/sec 
total size is 3709 speedup is 4.29 


kitkkttkettketttétékktütt OgCar cluster ttierterrerrsetrertteréráme 














done 


done 





cease oscarnode01 . oscardomain—-——————-- 

Shutting down GANGLIA gmond: [/ OK ] 

Starting GANGLIA gmond: [/ OK ] 

-—— oscarnode02 , oscardomain————————-— 

Shutting down GANGLIA gmond: [/ 0K ] 

Starting GANGLIA gmond: [ OK )] 

Cluster setup complete! 

--s Step 7: Successfully completed the cluster install [J 
cz 











7. kép Beavatkozást nem igénylő lépés: végső telepítési beállítások 
és tisztító folyamatok végrehajtása 


32 311 ZAN 





8. kép. Minden rendszer működik, a fürt bevetésre kész 


olyan alfeladatokra bontható, amelyek mindegyike a beme- 
netek egy adott csoportjával hajtja végre a keresést. Létez- 
nek is szoftveres megoldások ennek a feladatszétválasztás- 
nak a megvalósítására, ezek közül leginkább a nyílt forrás- 
kódú mpiBLAST és a kereskedelmi úton terjesztett Parcel 
érdemel említést. A BLAST párhuzamosított megoldásaival 
igen jó eredményeket lehet elérni, de természetesen elérhe- 
tünk egy olyan pontig, ahol már egyszerűen a csomópont- 
ok számának növelésével nem tudjuk tovább növelni a tel- 
jesítményt, mivel a kezdeti feladatszétválasztás munkatöbb- 
lete felemészti az így nyert teljesítményt. 

Az FPC egy másik általunk sokat használt alkalmazás, ame- 
lyet ujjlenyomatok képének összeillesztésére, szerkesztésé- 
re és vizsgálatára használunk. Ennek első párhuzamosított 
változatát a GSC fejlesztette ki, ez azonban még nem támo- 
gatta a kötegelt feldolgozást. A közelmúltban építettük 
össze a párhuzamosított FPC-t a Sun Grid Engine-nel, így 

a felhasználók egyszerűen igényelhetnek bizonyos számú 
csomópontot a program futtatásához. 

Dolgozunk egy bioinformatikai szolgáltatásokat megosztó 
egyenrangú alkalmazás, a Chinook kifejlesztésén is. Jelenleg 
ez még fejlesztési fázisban van, a saját fürtünkkel próbáljuk 
összeépíteni. Segítségével lehetőség nyílik majd a hálók 
összekapcsolására és ezzel a Globus eszközkészlet kiváltására. 
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Jelen pillanatban a 200 csomópontos fürtünk teljesítmé- 
nyét az emberi génállomány feltérképezése és osztályozá- 
sa köti le. Az emberi génállomány hozzávetőlegesen 
30.000 génből áll, az egyes géneket különféle algoritmu- 
sok segítségével vizsgáljuk. A géneket 1500-as csoportok- 
ba foglaljuk, amelyek egyszeri vizsgálata körülbelül négy 
napot venne igénybe egy 2 GHz-es Opteron gépen. 
Fürtök alkalmazása nélkül nem lenne lehetőség az ilyen 
kutatások folytatására. 


Osszegzés 

Az OSCAR eszközkészlet hosszú utat tett meg az első ki- 
adása óta. Egyre többen fedezik fel könnyű alkalmazható- 
ságát és egyszerű használatát s így egyre szélesebb körben 
élnek a fürtözés technológiájával. A bioinformatika mind 
nagyobb mértékben alkalmazza a nagyteljesítményű szá- 
mításokat. Valószínű, hogy a bioinformatikus közösség 
számára egyre elérhetőbbé válik egy olyan megoldás, 
amely minden eszközt magában foglal majd a párhuza- 
mos bioinformatikai alkalmazások egyszerű telepítéséhez 
és futtatásához. 


Köszönetnyilvánítás 

Köszönetet szeretnék mondani Mark Mayonak, Asim 
Siddiguinek és Steven Jonesnak a lehetőségért, hogy 

a GSC Linux-fürtjén dolgozhattam és felismerhettem 

az OSCAR-ban rejlő lehetőségeket. Köszönet illeti továb- 
bá az OSCAR fejlesztőcsapatát, a külső fejlesztőket és 

a felhasználókat, akik létrehozták ezt a nagyszerű kö- 
zösséget a nagyteljesítményű számításokkal kapcsolatos 
tudás és információk megosztására. Végül, de nem utol- 
só sorban hálámat fejezem ki az NCSA munkatársainak, 
akik rengeteg időt és fáradságot fektettek az OSCAR 
projekt fejlesztésébe. Személyes köszönetemet feje- 
zem ki Jeremy Enosnak, René Warrennek és Martin 
Krzywinskinek a cikkhez fűzött értékes megjegyzései- 
kért és tanácsaikért. 


Linux Journal 2004. november, 127. szám 


Bernard Lee, a nagyteljesítményű számítá- 
sok szakértője, a kanadai Michael Smith 
Génkutató Központ munkatársa, ahol felada- 
ta a Linux-fürtök kezelése és a bioinforma- 
tikai alkalmazások párhuzamos futtatási le- 
hetőségeinek kidolgozása. Tagja az OSCAR 
központi fejlesztőcsapatának és rajongója 

a Sun Grid Engine-nek. A bliobcgsc.ca 
címen érhető el. 


5 oscar.openclustergroup.org 
2 www.csm.ornl.gov/oscar0o4 


2 www.bcgsc.ca 


2 www.bcgsc.ca/gc/bomge/chinook 














Bloglines webszolgáltatások (folytatás) 


Néhány webes közösség gonosz módon bezárja a felhasználóit, 

a Bloglines ezzel szemben a nyitott megközelítés híve és megengedi, 
hogy saját parancsfájljainkkal irányítsuk a webszolgáltatás API felületét. 
Vágjunk bele és zárkózzunk fel kedvenc blogjainkkal. 


zeket a sorokat néhány nappal a 2004-es november 
ha 2-án tartott amerikai elnökválasztás után írom. Mint 

közismert politika függőségben szenvedő, kiélvez- 
hetem a számítógépesített modern érát, és az éppen aktuális 
bölcsességeket. Többé nem kell kapcsolgatnom a TV csator- 
nák között, vagy újságokat olvasnom a helyi könyvtárban; 
nyugodtan végigkövethetem a részleteket amint a jelöltektől 
a sajtóhoz majd a különféle partizán oldalakra kerülnek. 
Lépést tartani a rengeteg különféle híroldallal igen sok időt 
vehet igénybe. Mint az elmúlt néhány hónapban láthattuk, 
mindenki nyert valamit a hírösszesítő programok használa- 
tával, amelyek begyűjtik a weblogok, újságok és más, gyak- 
ran frissített lapok által készített RSS és Atom tartalmakat. 
Az összesítő, mint a neve is mutatja, ezeket tartalmakat 
rendezi könnyen áttekinthető listába. 
A Bloglines.com olyan Internetes kezdőpont amely web- 
alapú hírösszesítőt is kínál nekünk. Mindez önmagában még 
nem lepne meg senkit, hiszen a hírgyűjtemények, az összesí- 
tők és a web együtt szinte tálcán kínálják ezt a lehetőséget. 
Ráadásul a Bloglines nem is egyedi. Számtalan egyéb, igaz, 
talán nem annyira jól ismert Web-alapú hírösszesítő létezik. 
A Bloglines azonban egyedi szolgáltatást is kínál használó- 
inak, ugyanis a Bloglines belső adatbázisát felhasználva 
saját összesítőt vagy akár saját alkalmazást készíthetnek 
a Bloglines által összegyűjtött adatokból. Mindez az infor- 
máció ellenszolgáltatás nélkül hozzáférhető, egy viszonylag 
kötetlen szerződés mellett, valamennyi programozó számá- 
ra, akit érdekel a Bloglines motor eredményeinek össze- 
gyűjtése. Mivel a Bloglines körülbelül óránként blogok és 
honlapok százezrein keres frissítéseket, a webszolgáltatás 
API használói biztosak lehetnek benne, hogy legfrissebb 
weblog tartalomhoz jutnak hozzá. 
Legutoljára a Notifier API-t vettük szemügyre, amely egy 
adott felhasználó elérhető, de még olvasatlan gyűjteményé- 
hez enged hozzáférést. Megnéztük a Blogroll API-t is, 
melynek segítségével a felhasználó, ha úgy kívánja, megha- 
tározhatja vagy programjában felhasználhatja a gyűjte- 
ményre hivatkozó emberek listáját. Mit láthattuk, ezek 
a API-k sokat segítettek, ha az új weblog bejegyzéseket 
szeretnénk megtalálni, vagy ha saját gyűjteményt listát 
akarunk összerakni az érdekes weblogokból. 
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Valami azonban hiányzott a cikkben bemutatott lehetősé- 
gek közül. Jó dolog tudni, hogy az új weblog bejegyzések 

a Bloglines kedvenceink közé kerül, de még jobb lenne ha 
azt is tudnánk, melyik blog frissült éppen. Továbbá, nem 
rossz, hogy lekérdezhetem az aktuális feliratkozási listámat, 
de még boldogabb lennék, ha azt is tudnám, melyikük fris- 
sült, és pontosan mikor frissültek legutoljára, valamint hány 
bejegyzés van az egyes weblogokban és azok a bejegyzések 
mit is tartalmaznak. Más szóval, a jelenlegi Bloglines felüle- 
tet szeretném a sajátommal lecserélni, és az új weblog be- 
jegyzéseket olyan alakban megjeleníteni, amely nem feltét- 
lenül felel meg a Bloglines.com weblap által felajánlottnak. 
Szerencsére, a Bloglines webszolgáltatás fejlesztői lehetővé 
tették, hogy pontosan így járjunk el, mégpedig a sync API 
segítségével. Ebben a hónapban, folytatjuk a Bloglines 
webszolgáltatásainak felfedezését, és elmerülünk a sync 
API részleteiben. Megpróbálunk létrehozni egy saját, egy- 
szerű hírösszesítőt, amely rendelkezik néhány, a Bloglines 
felületből már ismert képességgel. 


Feliratkozások és elemek 

Végső soron a Bloglines és a hozzá hasonló hírösszesítők 
nem állnak másból, mint egy URL listából. A két hónap- 
pal korábban összerakott, Python nyelvű és Universal 
Feed Parser alapú hírösszesítőnk pontosan ilyen program 
volt — URL listát vizsgált egy fájlban és az adott URL- 
ekhez tartozó legfrissebb tartalmat gyűjtötte össze. 
Minden egyes weblog küldemény a lista egy-egy URL- 
jének felel meg. Ha az URL-t eltávolítjuk a feliratkozási 
listánkból, a hozzá tartozó küldemények többé már nyil- 
vánvalóan nem érdekesek a felhasználó számára, ezért 
nem is látja őket. 

Az a tény, hogy a Bloglines több felhasználóval dolgozik, 
azt jelenti, hogy nem elég egyetlen URL listát tárolnia, ha- 
nem azt is meg kell jegyeznie, hogy melyik URL melyik fel- 
használóhoz tartozik. Bár ez nyilván kicsit megbonyolítja 
a dolgokat, a modern magas szintű nyelvek segítségével 
nagyon könnyű megérteni a két adatszerkezet közötti kü- 
lönbségeket. Az URL lista egyszerű tárolása helyett egy 
hash táblát kell létrehoznunk, ahol a felhasználói azonosítót 
használjuk kulcsként értéke pedig az adott felhasználóhoz 
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1. lista A felhasználó feliratkozásainak megjelenítése 


$1!/usr/bin/per1 

use strict; 

use diagnostics; 

use warnings; 

use WebService: :Bloglines; 

my $username - "reuvenélerner.co.il" ; 
my $password - "MYPASS"; 

my $bloglines - 


I 


webService: :Bloglines-:new(username — 
$username , 
password —: 
$password) ; 


tf olvasottként akarjuk megjelölni? 

my $mark unread - 0; 

ff Milyen dátumtól kezdve szeretnénk letölteni? 
tt (ennek Unix időnek kell lennie) 

my $subscriptions - $bloglines-slistsubsO; 

if ($subscriptions) 


14 
íf a tartalmak listája 
my afeeds - $subscriptions-sfeeds0 ; 
tt Beszerezzük a tartalmak címét és URL-ét 
foreach my $feed (Aafeeds) ( 
my $title - $feed-sítitlek; 
my $ur1 - $feed-5(htmlur13; 
my $subid - $feed-síBloglinessubid?; 
print "Subscribed to "$title", " 
2. ssúubtd  "$súbEd rat "$úrlFXn 
3 
3 
else 
§ 
print "No subscriptions.n" 
ii 


tartozó lista lesz. Ha a felhasználó egyedi azonosítóját 
ismerjük, könnyedén nyomon tudjuk követni az adott 
felhasználó feliratkozásait. 

Természetesen, a Bloglines nem néhány ezer ember listáit 
tartja karban, hanem sok tíz vagy százezerét. Így nyugod- 
tan állíthatjuk, hogy nem ilyen naiv megvalósítást használ- 
nak, amely legfeljebb egy kísérlet, vagy néhány ember 
számára tervezett összesítő számára felelhet meg. A dolgok 
kicsit trükkösebbé válnak amikor megközelítjük a Bloglines 
felhasználói terhelését. A felhasználók feliratkozási listái 
nem lehetnek egyszerű URL-ek; sokkal valószínűbb, hogy 
az URL-ekhez rendelt azonosító számokat (vagy ahogy az 
adatbázis körökben nevezik , elsődleges kulcsot") használ- 
nak. Egy ilyen rendszernek megvan az az előnye, hogy 
több jelentkezőnek is lehetővé teszi a feliratkozást a lap 
hírösszesítőjére, a Bloglines a már meglévő feliratkozások 
alapján javaslatot tud tenni nekik , hogy mely további web- 
logok érdemesek még a figyelmükre. 

Ezek után nem okoz nagy meglepetést ha megtudjuk, hogy 
az új weblog küldemények lekérése a Bloglinestól két lépés- 
ből áll. Az első lépésben lekérjük a feliratkozások listáját, 
pontosabban a Bloglinestól lekérdezzük a felhasználóhoz 
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rendelt feliratkozási azonosítókat. Ezt követően utasítjuk 

a Bloglinest, hogy küldje el az adott felhasználóhoz és 

a kapott azonosítóhoz tartozó összes új elemet. 

A Bloglines webkiszolgáló API megvalósítása több különféle 
programnyelven is elérhető. Minthogy az új alkalmazásokat 
többnyire Perlben készítem, a webService: :Bloglines mo- 
dult fogom használni amelyet feltöltöttek a CPAN-ra, azaz 

a Comprehensive Perl Archive Network nevezetű világméretű 
web és ftp kiszolgáló hálózatra, amelyről a Perl és annak 
moduljai tölthetőek le. Az 1. listában látható egyszerű prog- 
ram (bloglines-listsubs.pl) megjeleníti a címet, a feliratkozás 
azonosítóját és a hozzá tartozó URL a felhasználó összes 
feliratkozására. Minden feliratkozáshoz további információ 
is elérhető; ezeket a webServi ce: :Bloglines, illetve 

a Bloglines API dokumentáció részletesen ismerteti. 
Amennyiben meg szeretnénk őrizni a felhasználók 
Boglines.com felületén látható sorrendjét , érdemes a folders 
függvényt használnunk az 1. listában olvasható feed függ- 
vény helyett. A feed ugyanis egyszerűen csak visszaadja 

a feliratkozásokat, a folders ellenben ugyanolyan szerkezet- 
ben adja őket vissza, ahogy azt a Bloglines lapján láthattuk. 


Feliratkozások letöltése 

Most már tudjuk, hogyan szerezhetjük meg egy adott 
Bloglines felhasználóhoz tartozó feliratkozás azonosítókat, 
így le tudjuk kérdezni a feliratkozás azonosítókhoz tartozó 
egyes elemeket is. Ezt mutatja be a 2. lista rövid programja 
amely letölti a felhasználó összes feliratkozását, majd vala- 
mennyihez megmutatja a legutóbb frissült elemeket. A ki- 
menete nem HTML, hanem egyszerű szöveges formátum, 
következésképpen a megjelenített hivatkozásokra nem tu- 
dunk rákattintani. Mindazonáltal nem különösebben nehéz 
egy ilyen programot cron feladatként lefuttatni és a kime- 
netét egy HTML fájlba irányítani, így percre friss, személy- 
re-szabott tartalomlistát kapunk. Természetesen a Bloglines 
ingyenesen biztosítja nekünk ezt a szolgáltatást valahány- 
szor csak belépünk a weblapjukra. Így aztán a program 
érdekes tesztje a Bloglines webszolgáltatásainak, de azok- 
hoz képest igazából nem nyújt semmi újdonságot. 

Az egyik ügyes húzás amit a Bloglines a webszolgáltatás 
definíciójában bevezetett , hogy HTIP visszatérési kódokat 
használ a hibák és szokatlan események visszajelzésére. 
Például, a 200 (OK) válaszkód azt jelzi, hogy van új beolva- 
sandó elem illetve, hogy a geti tems ($subId) egy vagy több 
ilyen elemet tartalmaz. A 304 (változatlan) válaszkód amely 
egyébként azt jelzi, hogy a HTML az utolsó lekérdezés óta 
nem változott, itt egy kicsit más szerepet kap; azt jelenti, 
hogy a az adott feliratkozó már az összes elemet látta ebben 
a feliratkozásában. A többi válaszkód (401, 403 és 410) azo- 
nosítási hibákat jelez, ami valószínűleg annak következ- 
ménye, hogy a kérelmező felhasználó elgépelte a Bloglines 
felhasználónevét, jelszavát, esetleg mind a kettőt. 

Sajnos Perl alatt e hibakódok kezelése messze van az opti- 
málistól. Lekérdezésükhöz az eval blokkon belül meg kell 
hívnunk a $bloglines-sgetitems O függvényt, majd köz- 
vetlenül az eval meghívását követően meg kell vizsgál- 
nunk a $d értékét. Ha a $( üres, feltételezhetjük, hogy 200- 
as (OK) HTTP válaszkódot kaptunk és vannak beolvasandó 
új elemek. Amennyiben azonban értéket tartalmaz, újra kell 
írnunk a kimeneti üzenetet, ahogy azt a 2. listában meg is 


2. lista bloglines-getitems.pl 


t!/usr/bin/per1 
use strict; 
use diagnostics; 
use warnings; 
use WebService: :Bloglines; 
my $username - "reuvendlerner.co.il"; 
my $password - "MYPASS"; 
my $bloglines - 
webService: :Bloglines-:new(username 
password 


-5 $username, 
-. 
$password) ; 
tf olvasottként akarjuk megjelölni? 
my $mark unread — 0; 
ft Milyen dátumtól kezdve szeretnénk letölteni? 
4 (ennek Unix időnek kell lennie) 
my $subscriptions - $bloglines-slistsubsO; 
if ($subscriptions) 
í 
f a tartalmak listája 
my efeeds - $subscriptions-sfeedsO ; 
foreach my $feed ((Afeeds) ( 
my $title $feed-sítitlel; 
my $ur1 - $feed-5(htmlur13; 
my $subid - $feed-síBloglinessubid?t; 
print "Subscribed to "$title", " 
e ésúbtatéssúbma ató es útle nsés 
my $update; 
ft Elkapjuk a hibákat ! 
eval ($update - $bloglines-sgetitems($subId) ; 3; 


tettük. Amennyiben ezt a metódushívást nem tesszük eval 
blokkba, akkor sajnos a programunk végzetes hibával leáll, 
amint a 200-as válaszkódon kívül bármi mást kapunk. 
Végül a Bloglines funkcióit két opcionális paraméter teszi 
teljessé. Az első n-ként ismert paraméter egyszerű igaz- 
vagy-hamis érték (1 vagy 0) amely értesíti a Bloglines-t , 
hogy frissítenie kell-e a , már láttam" bitet az éppen letöltött 
cikkeknél. Egyébként amikor a felhasználó a Bloglines.com 
webes felületén keresztül nézi a weblog küldeményeit ezt 
mindig 1-re állítjuk, ami azt jelenti, hogy a korábban elolva- 
sott cikkek újra már nem kerülnek elő. Talán, mivel tudták, 
hogy a webszolgáltatások API más hírösszesítő alkalmazá- 
sokat is kiszolgál, a Bloglines bölcsen 0-ra állította ezen 
érték alapértelmezését az API-ban. 

A második, d nevű opcionális paraméter azt az első dátu- 
mot mutatja meg a Bloglinesnak amelytől kezdve az adott 
honlap cikkeit le szeretnénk tölteni. Az érték UNIX időfor- 
mátumban értendő, azaz 1970 január elseje óta eltelt má- 
sodpercek számát kell megadnunk. Ezt a számot a nagyobb 
nyelvek mindegyikében készen kapjuk, és segítségével 
nagy pontossággal meg tudjuk adni, hogy pontosan milyen 
mélyen szeretnénk az adott honlap Bloglines tárolta törté- 
nelmébe nyúlni. 


Osszefoglalás 

Az igazat megvallva lelkes Bloglines felhasználónak tartom 
magam, annak ellenére, hogy pontosan tudnám hol is van 
a lap és a cég székhelye. Nehezen tudom elképzelni, hogy 
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ft Figyeljük a hibákat, kiírjuk ha nincs változás. 
Ta (SO 
if C$a -- /A304 No Change/) ( 
print "Vt No change" ; 


3 
else ( 
DEANE ENE EFror code" S$a 
. "retrieving updates.m"; 
d 
i 
ft Nincs hiba? Néhány alap dolgot kiírunk az 
elemekről . 
else 
ú 
foreach my $item ($update-sitems) 
ki 
my $title — $item-sítitlek; 
my $creator z $item-5(dcl-sícreator)l; 
my $link - $item-b(flinkh; 
my $pubDpate - $item-5(pubDatel; 
print At$title by $creator " 
. "on $pubDate ($1linkdw"; 
3 
s 
s 
s 
else 
í 
print "No subscriptions.n" 
bi 


továbbra is ingyenes és reklámmentes marad, hacsak fej- 
lesztői nem jótékonyságból cselekszenek vagy végzetesen 
naivak. Kedvelem a kiváló felületét, a tényt, hogy könnye- 
dén el tudom érni azokat a weblogokat amelyektől politi- 
kai éleslátásom függ (vagy éppen mulatságom, attól függő- 
en ki hogyan ítéli meg az ilyen bölcsességeket) és gyors, 
hibatűrő képességeit. 

Azonban ahogy az Amazon, eBay és Google megmutatta az 
elmúlt néhány évben, nyers adatainkhoz webszolgáltatás 
felületet adva olyan új kreatív alkalmazásoknak nyitunk 
kaput, amelyekre a belső fejlesztők álmukban se gondoltak 
volna. A Bloglines mostanában kezdte el funkcióit 
webszolgáltatások formájában közzétenni, és igaz ugyan, 
hogy mindez egyelőre csak kezdeti és kísérleti lépés, a ma- 
gam részéről nagyon ígéretesnek látom. Alig várom, hogy 
olyan alkalmazásokat lássak, amelyek erre az API-ra vala- 
mint a Bloglines és versenytársai által kiadott további API 
felületekre épülnek, hogy a Bloglines lapját tegyék a web- 
logok, olvasók és fejlesztők Mekkájává. 
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Az Oddmuse wiki motor 


A wikik mókásak és nagyon hasznosak. Próbaképpen telepítsük Alex Schroeder 


Oddmuse programját. 


z első wiki weboldalt, a WikiWikiWeb-et, 1995-ben 
A Ward Cunningham hozta létre a Portland Pattern 

Repository Project számára. Az azóta eltelt idő 
alatt számos wiki motort fejlesztettek különböző program- 


nyelveken. Az egyik ilyen wiki motor Alex Schroeder Perl 
nyelven íródott Oddmuse programja. 


Mi a Wiki? 

Bár wikik közel egy évtizede léteznek, úgy tűnik népszerű- 
ségük töretlenül növekszik, és sok ember még csak most ta- 
lálkozik a wiki-koncepcióval. Ezért talán érdemes egy rövid 
áttekintést adnunk a wikikről. Aki már jól ismeri a wikiket, 
nyugodtan a következő fejezetre ugorhat. 

A wiki alapelve egyszerű: olyan weboldalról van szó, amely 
minden felhasználó számára lehetővé teszi, hogy kizárólag 

a böngészőt használva bővítse vagy szerkessze azt. Ez az egy- 
szerű elképzelés nagyon hatásosnak bizonyult, hiszen renge- 
teg önkéntes fejlesztőnek teszi lehetővé, hogy közös munká- 
val készülő weboldalakat hozzanak létre. A wiki azonban ki- 
sebb csoportok vagy magányos szerzők számára is nagy se- 
gítség, akik egyszerűen szervezhetik és hozhatják létre infor- 
mációikat. Ahogy egyszer Cunningham mondta: , (A wiki] 

a legegyszerűbb on-line adatbázis ami egyáltalán működhet." 
Tapasztalataim szerint a wikik nagyon hasznos eszköznek bi- 
zonyulhatnak. Segítségükkel projekteket szervezhetünk, és 
dokumentációt készíthetünk szinte bármiről, meglepő módon 
sokkal fájdalommentesebben és kevésbé időrabló módon 
mint egyébként. Talán a legegyszerűbben úgy érthetjük meg 
a wiki lényegét és működését, ha megnézzük milyen minősé- 
gű dokumentumok hozhatók létre, és felkeresünk egy felnőtt, 
bejáratott wiki lapot. Kiváló példa erre a Wikipedia. 

A Wikipedia egy enciklopédia, éppen olyan mint egy többkö- 
tetes, kinyomtatott-bekötött enciklopédia. A bekötött enciklo- 
pédiáktól eltérően azonban a Wikipedia hatalmas , szerkesz- 
tői gárdával" rendelkezik amelynek bármely böngészővel 
rendelkező Internet felhasználó tagja lehet. Ezen kívül min- 
den egyes cikk szövege a megfelelő helyeken hivatkozásokat 
tartalmaz más Wikipedia cikkekre. A lap látogatói cikkeket 


hozhatnak létre , átszerkeszthetik a meglévőket. Változtatá- 
saik és bővítéseik pedig azonnal hozzáférhetőek lesznek 

a többi felhasználó számára. A változásvezető rendszer segít- 
ségével ezek a módosítások könnyedén elmenthetők, ami ol- 


talmat nyújt a tévedésből elkövetett vagy rossz szándékú 
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1. ábra Jellemző Oddmuse laplábléc, a megszokott wiki funkciókkal: 
a lap szövegének szerkesztése és keresés 











S zeMap I RezenChan ges [EIN a 
Editing What Is A Wiki 
wiki is a website that usually has the following two properties: a 





Anybody can edit the pages of the wiki, and anybody can undo these edits 
It is easy to write new pages for the wiki, because it doesn!t use HTML 


There are exception to both rules.) 
ferences: 
WhatIsaliiki on Meatball wiki [http ://www , usemod. conm/cgi-bin/mb . plyuhatTsatiki] 
"A wiki is the simplest online database that could possibly work." Ward 
http: //wiki . org/wiki . cgivwWhatIswiki] 
Why a wiki? sz 


ith a wiki, creating and maintaing a website is trivial: You don"t need to know HTML, 
r FTP, nor anything else. This is what people normally use for their websites. 


wiki is great if you want to enable other people to help and contribute. 
he wiki just helps them to start contributing faster, since ít ís so easy to use. 


— wiki is also Groupware 5 
wiki is ideal for a small group of people: classes, friends, project teams, gaming 


roups., It allows the group members to communicate with each other when you do not or [/ 
annot meet each other face-to-face. A wiki also works for chat rooms. Often the logs [e] 











2. ábra A lapformátum jellemző szerkesztőszövege. A képernyőképen 
nem látszanak a Preview (előnézet) és Save (mentés) gombok. 


módosításokkal szemben. Hogy fogalmat alkothassunk, 
mennyire könnyen vihetünk tartalmat a wikibe, képzeljük 
el, hogy valamilyen wiki weboldalon éppen a rágcsálókról 
olvasunk cikket. Feltűnik nekünk, hogy bár igazán szépen 
megírt cikk, elfelejtett említést tenni a világ legnagyobb ma 
is élő rágcsálójáról, a vízidisznóról. A figyelmetlenséget javí- 
tandó, rábökünk a lap hivatkozásai közt található Edit szö- 
vegre (miután kitöltöttük a szerkesztéshez szükséges szab- 
ványos Web-űrlapot). Ezáltal be tudjuk gépelni a vízidisznó- 
ról szóló mondatunkat, és amint kimentettük a módosításo- 
kat, a cikk új verziója máris mindenki rendelkezésére áll. 
Ilyen egyszerű. 

Tegyük fel, hogy a cikkben elhelyeztünk egy hivatkozást 
Dél-Amerikára, hiszen ez a vízidisznó élőhelye és azt szeret- 
nénk, ha a Dél-Amerika szó a Dél-Amerikáról szóló cikkre 








mutatna. A hivatkozás létrehozásá- 
hoz mindössze az egyszerű wiki 
csatolási szabályt kell ismernünk 
(ha a lap Oddmuse-t használ, a Dél- 
Amerika szót dupla szögletes záró- 
jelbe kell helyeznünk) és a lap 
elkészítésekor a wiki motor auto- 
matikusan létrehozza a Dél-Ameri- 
káról szóló cikkre mutató hivat- 
kozást. Amennyiben nincs még 
Dél-Amerikáról szóló cikk, a wiki 
motor létrehoz egy űrlapot, ahol 
bárki elkészítheti a hiányzó cikket. 
Így aztán a wiki cikkről-cikkre 
bővül és egyre hasznosabb lesz. 
Egy másik példa, amely jól mutatja 
milyen hasznos tud lenni a wiki 
kis csoportok számára is, az álta- 
lam és üzleti partnereim által hasz- 
nált oldal. Ezt műszaki informáci- 
ók rögzítésére, például kiszolgáló 
beállítások megváltoztatására, 
projekt dokumentálásra, program- 
telepítésre, általános feladatok 
szokásos megoldására és egyéb 
feladatokra használjuk. Ezen kö- 
vetjük nyomon üzleti adatainkat 
is, például az ügyfelek adatait. 
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5." Keine Ahnung, Erfahrungsgemáss braucht das Abspeichern von lüngeren Oddmuse 
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5.4 Auf Deutsch? Gehts jetzt oder gehts nicht? 








3. ábra Az Oddmuse jól olvasható eltérés-megejelnítője 
kiválóan mutatja mi változott meg az egyes 
verziók között 
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History of Comments on Migrating From 
UseMod 





2:52 UTC by RolfUnger from 

isdip.tiscalizle — new comment 

104-05-09 0204 UTC by Alex Schröder from 

2.delienthispeed.ch — Neuer Kommentar 

. 2004-05-OB 00:20 UTC by RolfUnger from p213.54.167.6.tisdip-tiscali.de 
iment 

a a . 2004-05-7 23:24 UTC by Alex Schröder from 

4-239 delient.hispeed.ch — Looking at the source, ít seems that the summary 
field shouki be extracted just fine. 

Revision $ . . . . 2004-05-07 2224 UTC by Alex Sehrőder from 
80-219-234-239.delient.hispeed.eh — Neuer Kommentar 

Revissun 4 , , , , 2004-05-O7 20:28 UTC by RolfUnger from p5088B3B97.dip.t-díialin.net -— 
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4. ábra Jellemző történet lap. A jelölőnégyzetek 
segítségével a felhasználó beállíthatja mely lapok közötti 
különbségekre kíváncsi. 


hogy az Oddmuse érvényes HIML 
4.01 Transitional lapokat készít. 
Kiegészítésként érdemes megje- 
gyezni, hogy szépen együttműkö- 
dik a Cascading Style Sheets (CSS) 
technikával is. Ha szeretnénk 
hírgyűjteményt kiadni RSS-en 
keresztül, az Oddmuse egyaránt 
támogatja a wiki lapunkhoz készí- 
tett kimenő RSS tartalmat és a hír- 
gyűjtemény készítésére szolgáló 
bejövő RSS tartalmakat. 

A wiki lapok egyik nagy kérdése 

a vandalizmus. Végül is mi gátol- 
hat meg valakit abban, hogy egy 
honlapot szerkesztve valamilyen 
módszerrel teleszemetelje azt? 
Amennyiben meg szeretnénk őriz- 
ni a wiki egyik legnagyobb elő- 
nyét, nevezetesen, hogy bárki 
képes lapokat szerkeszteni és lét- 
rehozni, kénytelenek vagyunk 
nyitottan hagyni a lapokat és ma- 
gunk helyreállítani az elrontott 
oldalakat. Szerkesztők figyelmes 
csoportja a RecentChanges (friss 
változások) lapon könnyen felde- 
rítheti a vandalizmus nyomait. 


Az előnyök teljesen nyilvánvalóak 

számunkra. Az elmúlt idők tapasztalatai alapján meg kellett 
állapítanunk, hogy a rendszeradminisztráció és projektdo- 
kumentáció lényegesen nagyobb része került rögzítésre ami- 
óta wiki-t használunk. Ezen felül az adatok kereshetőek és 
könnyen szerkeszthetőek. Ráadásul, mivel a cikkváltozások- 
hoz és megjelenésekhez RSS tartalmat is szolgáltatunk, min- 
den érintett könnyedén nyomon követheti az eseményeket. 


Oddmuse képességei 

Az Oddmuse egyetlen Perl script. Ezzel a telepítés jelentő- 
sen leegyszerűsödik és egyben megfelel a Schroeder-projekt 
egyik céljának: az Oddmuse legyen egyszerű és könnyen 
használható. A rugalmasság elvesztését az Oddmuse bővít- 
hetősége ellensúlyozza. Bizonyítékként, a projekt honlap- 
ján megtalálhatjuk az elérhető modulok listáját. 

A szokásos, kötelező wiki elemek mellett (utolsó változtatá- 
sok automatikus követése, hatékony hivatkozási jelölés- 
rendszer, verziókezelés és az egyes változatok különbségei- 
nek vizuális megjelenítése,) az Oddmuse számos további 
figyelemre méltó képességgel és előnyös tulajdonsággal 
rendelkezik. Az egyik ilyen dolog ami mély benyomást tett 
rám, az Oddmuse dokumentáció minősége. Schroeder nagy 
figyelmet fordít a különféle nyelveken megjelenő bőséges 
dokumentációra és ennek meg is van az eredménye. Stílu- 
sosan az éppen dokumentált eszközt használja a dokumen- 
táció karbantartására és készítésére. Az Oddmuse projekt 
weblapjára látogatva mindjárt a motort is megtekinthetjük 
működés közben, és bőséges információt találunk arról, 
hogyan állíthatjuk be és szabhatjuk testre. 

Olyan ember lévén, aki a szeret megfelelni a World Wide 
Web Consortium (W30) szabványainak, örömmel láttam, 
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Amennyiben viszont hajlandóak 
vagyunk lemondani a nyílt szerkesztés előnyeiről és inkább 
a vandalizmust szeretnénk megfékezni, az Oddmuse két 
módszert is kínál erre. Lezárhatunk adott oldalakat vagy 
akár az egész honlapot, illetve jelszavakkal biztosíthatjuk bi- 
zonyos személyeknek a szerkesztési hozzáférést. Másik lehe- 
tőség, hogy egyszerűen kitiltjuk a problémás felhasználókat. 
Az Oddmuse MYSOL vagy PostgreSOL adatbázis helyett 
egyszerű állományokat használ adattárolásra. Sok érvet le- 
het felhozni amellett, hogy miért előnyös ez, és épp ilyen 
sok érv szól amellett is, hogy miért hátrányos. Egy részről 
sima állományokat használni adatbázis helyett adminisztrá- 
ciós szempontból mindenképpen egyszerűbb. Más részről 
az adatbázisoknak is megvannak az előnyei, főként az adat- 
tárolás és visszakeresés terén. Ha úgy érezzük wiki oldalun- 
kat kizárólag adatbázis háttérrel tudjuk elképzelni az 
Oddmuse-t nem nekünk találták ki. De ha csak a sebesség 
miatt aggódunk, érdemes megemlíteni, hogy a keresés 
meglehetősen gyors. Jó példa erre az Oddmuse alapú Emacs 
Wiki, amely jelenleg 2,242 lapot tartalmaz. 


Telepítés 

Az Oddmuse weblap telepítésről szóló részében a telepítéssel 
és beállításokkal kapcsolatos legfrissebb parancsfájlokra és 
útmutatókra találunk hivatkozásokat. Az alapbeállítás rend- 
kívül egyszerű. Miután letöltöttük a parancsfájlt, egyszerűen 
helyezzük el a CGI könyvtárunkba és tegyük végrehajtható- 
vá. Azon nyomban működnie kell. Ha nem így történik néz- 
zünk utána a dolognak az Oddmuse hibaelhárító oldalain. 
Még ha nem is tervezzük a wiki átalakítását, egy dolgot 
mindenképp érdemes elvégezni mielőtt bármi máshoz kez- 
denénk. Nevezetesen a parancsfájlban módosítanunk kell 
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Updates in the last 28 days 





I days 3 days 17 days! Vá days 121 days 128 days 
List alt changes ! Inciude minor chunges 
List later changes 


2004-05-11 


9 22:52 UTC (duff) (history) Comments on Migrating Frum UseMod . . . . RolfUnger from 
p213.54.133.246.tisdip.tiscalide — new comment len, de) 

6. 19:45 UTC (Jduff) (history) Selber Hosten . . . . PDJEAAODO.dip4-dialin net [de] 

6 10:15 UTC (dutf) (history) Migrare Da UseMod . . . . host162-31 .pool8$1 72.interbusiness. it — 
Migrating UseMod ITA 


2004-05-10 


6 22:12 UTC (diff) (history) Portraits Support Extenstow . . . . Alex Schröder from 
80-219-227-1 50.delient.hispeed.ch — simplified the code a bit, and so now span.new is 
needed anymore, [en] 

6 20:53 UTC (daff) (history) Cormrments on URL Abbreviattons . . . . Alex Schröder from 
80-219-227-1 50.delient.hispeed.ch — Neuer Kommentar [en] 

6 1406 UTC (dútf) (history) Serpt Mukpb . . . . host162-31.pool8172.interbusíness.ít — 








4. ábra A friss változásokat követő lap jellemző kinézete 


a $DataDir változót, hogy annak a könyvtárnak az abszolút 
útvonalát tartalmazza ahol az Oddmuse majd az adatait 
tárolni fogja. Ha ezt a változót nem írjuk át, az Oddmuse 

a /tmp/oddmuse könyvtárat fogja adatkönyvtárként használ- 
ni, így könnyen elveszthetjük adatainkat. 

A másik dolog amit érdemes megtenni, függetlenül attól, 
hogy milyen egyszerű vagy bonyolult wiki beállítást szeret- 
nénk összehozni, az adminisztrátor és a szerkesztő jelszavá- 
nak beállítása. A megváltoztatandó változók a $AdminPass 
és $EditPass lesznek. Mivel a jelszavak egyszerű szöveges 
állapotban tárolódnak, a wiki lapunk biztonsága éppen 
annyira erős, mint a kiszolgálóé általában. Ettől függetlenül 
érdemes erős jelszavakat választani. 

Bár az alaptelepítés teljesen jól működő Oddmuse wiki lapot 
készít, melyen valószínűleg mindent megtalálunk amire 
szükségünk van, esetleg érdemes fontolóra venni egy komo- 
lyabb telepítést is. Magam részéről a komolyabb telepítést 
választottam a mostanában feltett Oddmuse wiki lapjaim- 
hoz, és úgy vélem, a kapott rugalmasság bőségesen megéri 
a beállításokkal járó plusz fáradtságot. 

Először is a weblapon egyértelműen leírt csomagoló- 
parancsfájl módszert használtam. Ezzel a módszerrel nem 
szükséges minden parancsfájl-frissítés után újra megadni 
az adatkönyvtár nevét. Másodszor külső beállításfájlt hasz- 
náltam, azon belül pedig külső CSS állományt adtam meg. 


Beállítások 

Az Oddmuse wiki lapunk most már működőképes, úgy- 
hogy tetszés szerint állítgathatjuk. Néhány beállítást magá- 
ban a wikiben is elvégezhetünk például zárolhatjuk a lapo- 
kat vagy, ha nem szeretnénk nyílt wikit üzemeltetni, akár 
az egész honlapot. 

A beállítások megváltoztatásához és egyéb wiki adminiszt- 
rációs feladatok elvégzéshez adminisztrátorként kell azo- 
nosítani magunkat. Ehhez viszont meg kell látogatnunk 

a jelszólapot. A jelszólapra nincs külön hivatkozás, ezért 
nekünk kell begépelni a következő URL-t: 
http://www.example.com/wiki/ 
current.cgi?action-password 


Természetesen saját gépünk nevét és saját elérési utunkat 
kell használni. A fenti LIRL példában az Oddmuse CGI prog- 
ramot azért nevezik current.cgi-nek mert a csomagoló pa- 
rancsfájl telepítési útmutatót követtük. Miután azonosítottuk 
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magunkat, tetszés szerinti beállításokat végezhetünk a lapok 
láblécében megjelenő különleges menüpontokat használva. 
További változtatások közvetlenül a parancsfájl módosításával 
végezhetők el. Számos programváltozót igazíthatunk az igé- 
nyeinkhez. Ha külső beállítás-állományt szeretnénk használ- 
ni, a programváltozókat természetesen ott tudjuk átállítani. 

A weblapon részletes leírást találunk minden programvál- 
tozóhoz. Ezekkel a változókkal vezérelhetjük például a wiki 
nevét, a használt stíluslapot, a lapok láblécében megjelenő 
jelvényünk URL-jét és egyéb értékeket. 

Nagyon örülök, hogy Schroeder beépítette a CSS támogatást 
az Oddmuse-ba, hiszen ezáltal sokkal könnyebben tudjuk 
megváltoztatni a wiki kiosztását és kinézetét mint egyéb- 
ként. Miután a wiki elkészült és futásképes, néhány percet 
szántam a stíluslap alakítgatására, míg végül el nem értem 
a nekem tetsző wiki kinézetet. 

Ezen kívül a modulok és kiterjesztések beépítésével további 
jelentős változtatásokat vezethetünk be a wikinkbe, sőt akár 
saját változatot is készíthetünk. Az Oddmuse Weblapon meg- 
találjuk a modulok és kiterjesztések teljes listáját. Ha úgy 
tetszik az Oddmuse-t akár blogrendszerré is formálhatjuk. 


A Wiki életrekeltése 

Amikor elégedettek vagyunk a wiki telepítésével és beállítá- 
sával, elkezdhetjük a lapokat szerkeszteni. Mielőtt nekifog- 
nánk azonban, mindenképpen javaslom, hogy olvassuk 

el a az Oddmuse weblap szövegformázási szabályok (Text 
Formatting Rules) fejezetét. Miután megismertük a sza- 
bályokat, a lapok létrehozása és szerkesztése nem nehéz 
feladat, de felbecsülhetetlenül hasznos ha tudjuk mire 
képesek ezek a szabályok. 

Egy új wiki alapítóiként, többre lesz szükségünk egyszerű 
műszaki részletek ismereténél. A wiki sikere az alkotók je- 
lentkezésétől függ, így a közösségi szempontokat legalább 
annyira figyelembe kell venni mint a műszaki szempontokat. 
Ez jelentősen megbonyolítja a dolgokat. Végül is a közössé- 
geket nem tölthetünk le tarlabdaként make-fájllal!! Nekünk 
kell jelentkezésre ösztönöznünk és lelkesítenünk az embere- 
ket majd nevelgetnünk a wiki körül növekvő közösségünket. 
Ez időrabló foglalatosság és aligha adható rá pontos recept. 
Szerencsére a wikik alapítói vették maguknak a fáradtságot 
és megírták tapasztalataikat. Kiváló forrás a MeatballWiki 
honlap WikiLifeCycle oldala (melyet a források között meg- 
találunk). Ebből megtudhatjuk milyen módszerekkel gyűjt- 
hetünk szerzőket, hogyan válasszunk nevet, jelöljük ki 

a határokat, miképpen válasszuk meg a wiki célját vagy 
küldetését, hogyan alakítsuk ki a viselkedési elvárásokat, 
előzzük meg a pangást és így tovább. Most, hogy felvértez- 
tük magunkat egy jól beállított wiki oldallal és megértettük 
a közösségi kérdések alapjait, már semmi sem állíthat meg 
bennünket egy virágzó wiki oldal felé vezető úton. 


Linux Journal 2005. március, 131. szám 


Brian Tanaka 1994 óta foglalkozik UNIX rendszer- 
adminisztrációval és olyan cégeknél dolgozott 
mint a The Well, SGI, Intuit és a RealNetworks. 
A btanakaowell.com címen érhető el. 
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Linux-sokszorosítás iskolai gépekre 


Középiskolánkban sikerült egy UHU-linuxra mindazon alkalmazásokat feltelepíte- 
nem, amelyekről úgy gondoltam, hogy hasznosak lehetnek a diákok számára, majd 
az így kialakított rendszer sokszorosítására kidolgoztam egy egyszerű módszert. 


szokásos OpenOffice.org-on, gépíróprogramokon 
A (tpgt, ktouch), és adblock-kal illetve webdeveloper- 

rel kiegészített Firefox böngészőn túl -— leginkább 
a különböző szakkörökre járók kedvéért — telepítettem még 
néhány hasznos alkalmazást. Ilyen a Xored cég által módo- 
sított (szabad programként letölthető) Eclipse fejlesztői kör- 
nyezet, valamint a NuSphere PhpEd nevű programja, amely 
PHP programok nyomkövetését teszi lehetővé. (Az Eclipse 
megvan .uhu csomagban is, de nem sikerült úgy beállíta- 
nom, hogy lehessen PHPt-t is futtatni benne.) Kdevelop is 
felkerült, de ebben a PHP-hoz nem találtam nyomkövetőt. 
Természetesen a Kylix sem maradhatott el. 
Iskolánk egy pályázat keretében néhány éve megvette 
a Maple7 programot. Ez, az akkori technikai szintnek meg- 
felelően Windows 98 alatt fut, Windows XP alatt azonban 
már nem. A viszonteladó cég széttárta karjait: sajnos nincs 
mit tenni, meg kell venni az új változatot. Szerencsére 
a telepítő CD-n található linuxos változat még mindig 
nagyszerűen működik. A Crossover Office is gond nélkül 
indítja például az oktatáshoz szükséges Comenius Log0-t. 
Az iskolánkban kiosztott T192-es grafikus kalkulátorokat össze 
lehet kötni számítógéppel a TI-link program segítségével. 
Webkiszolgálót, valamint postgresgl, mysgl és firebird 
adatbáziskezelőket is feltettem, bár ezek nem indulnak au- 
tomatikusan. A DBDesigner4-gyel grafikus felületen lehet 
adatbázist tervezni, sőt, adatbázishoz kapcsolódva ki lehet 
rajzoltatni annak szerkezetét. A programnak ugyan nincs 
Postgresgl kiviteli lehetősége, de a www.osb.hu/z/My2Pg 
Perl szkript elvégzi ezt a konverziót. 


Előkészületek a klónozáshoz 

Nem érdemes 5 GB-nál kisebb helyet adni az IHU 
Linuxnak (ez lehet logikai partíció is). Én 3.6 GB-tal kezd- 
tem, de kicsinek bizonyult. Jó esetben van egy bőséges 
helyet biztosító Samba kiszolgáló is a hálózatban. 

A képmástájl készítése során igen jó szolgálatot tett 

a SystemRescueCD, amely a Linuxvilág mellékleteként nem- 
rég megjelent, de le is tölthetjük a webhelyéről. Ezen megta- 
lálható a képmás-fájl elkészítéséhez és visszaállításához re- 
mekül használható partimage program. (Erre a célra más jó 
programok is léteznek. Ilyen például a dump/restore páros.). 
A képmás-tájl mentéséhez a partimage programot interak- 
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tív üzemmódban használtam, ellentétben a visszaállítással, 
amit parancssorból, automatikusan érdemes végrehajtatni. 
Az interaktív használat annyiban jó, hogy az esetleges mu- 
lasztásokat (például kiírandó partíció lecsatolása) kedvesen 
közli velünk, és lehetőségünk van magyarázó szöveget is 
írni az elmentett partícióról, ami jó lehet olyankor, ha már 
sok próbálkozásunk volt, és valamelyik korábbi (ismert) 
fázisba szeretnénk visszatérni. 

Sajnos a bz2 tömörítményként való mentés valami miatt 
nem működött, de mivel általában nagyobb kincs az idő, 
mint a tárhely, a zip tömörítés is teljesen megfelelő. 

A partimage-et lehet egy kiszolgáló közbeiktatásával is 
használni, de nálunk az iskolai gépeket ellátó szerveren 
nem UHU Linux van, hanem Fedora, az erre fordított 
partimage pedig valahogy nem volt kompatibilis az általam 
használttal. Pedig ez sok bosszúságon átsegített volna... 

Így a helyi gépen készült képmás-fájlt egyszerűen felmásol- 
tam a Samba szerverre, annak is a publikus részére, hogy 
később ne kelljen jelszót megadni (törölni vagy felülírni 

így sem tudják mások, ha jól van beállítva). 


A nagy sokszorosítás 

Az előkészületek után eltöprengtem azon, hogy pontosan 
hogyan is érdemes a képmás-tájlt sokszorosítani. Hasonló 
helyzetbe kerülhet egy netkávézó vagy egy teleház rendszer- 
gazdája, ahol szintén érdemes lehet bizonyos időközönként 
újratelepíteni a gépeken futó programokat. Nagy szerencse, 
ha ugyanolyan gépekről van szó, mint ebben az esetben. 
Ami a merevlemezek felosztását illeti, rendszergazdánk 
már eleve meghagyott 20 GB-ot a Linux számára, 

de azért volt még mit tenni. Hogy gyorsabban haladjak, 

a nálam levő többféle linuxos boot-CD-ről indítgattam 

a gépeket a particionálás végett. A friss SuliX-szal annyi- 
ban meggyűlt a bajom, hogy - az első verzióval ellentét- 
ben - ezen most nincs cfdisk, csak sima fdisk, és ez 

csak akkor dolgozott pontosan, ha cilinderszámot adtam 
meg nem MB-ot. (Az fdisk másként számolja például 

a 45000MB-ot, mint a cfdisk, márpedig itt fontos, 

hogy pontosan ugyanolyan partíciók keletkezzenek). 
Munka közben érdemes jegyzetelni, mert — különösen 

ha nem sorban haladunk - könnyen előfordulhat, hogy 
elfelejtjük, mivel mit is csináltunk pontosan, és akkor most 
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hol is van a hogyishívják. Bátrabbak próbálkozhatnak az 
sfdisk-kel, ami parancssorból tud particionálni (interaktív 
közreműködés nélkül). A később említendő autorun fájlba 
ezt is be lehet írni, bár én jobbnak láttam ezt a lépést óvato- 
sabban, kézzel elvégezni. 

A képmás-tfájlok gépekre írása során két úton is haladhatunk. 
Akinek kevés gépet és nem túl gyakran kell klónoznia, annak 
megfelelő lehet a , gyári" SystemRescueCD is, aminek indulá- 
sakor be kell írni egy viszonylag hosszú paraméter sorozatot. 
Aki viszont szán egy kis energiát arra, hogy újraírja a tele- 
pítő CD-t a saját képmására szabott alapértelmezett para- 
méterekkel, annak a rászánt idő valószínűleg bőven megté- 
rül a későbbiekben. 

Nézzük először a ,gyári" SystemRescueCD használatát. 
Még ebben az esetben is fontos szempont, hogy úgy töltsük 
be a gépeket, hogy ki lehessen venni munka közben belőle 
a CD-t, illetve automatikusan el lehessen érni egy/több el- 
készített parancsfájlt egy Samba szerverről betöltés után, 
amit a CD módosítása nélkül is módosítani lehet. 

Erre a következő parancs szolgált segítségül (amit a booto- 
lás előtt lehet megadni): 

fb800 cdcache setkmap-18 ar nowait autoruns-72,3,8 
sar source-//szervergepunk/pub 


vagyis frame buffer üzemmód, 800x600 felbontással. 

A setkmap (vagy nokeymap) paraméter megadásával kikü- 
szöbölhetjük, hogy betöltés közben várjon a gép, míg meg- 
adjuk az általunk igényelt billentyűzet-kiosztást. 

Az ar. nowait azt jelenti, hogy a rendszer az autorun után 
ne várjon az ENTER leütésére autoruns-ként megadott szá- 
mokkal befolyásolhatjuk, hogy az ar. source könyvtárban 
elhelyezett autorun1, autorun2, autorun3... fájlok közül 
melyik fusson le. Ha nem írunk ilyen számsort, akkor csak 
az autorun fájlt fogja lefuttatni. 

Szintén egy sokat átszenvedett tanulság, hogy az autorun 
parancsfájlok csak egysorosak lehetnek, viszont szabad 
pontosvesszót használni a parancsok elválasztásához. 

Itt a 2-es fájlba beírtam, hogy 

umount /mnt/cdrom; eject 


aminek hatására ki lehetett venni a cd-t a klónozás megkezdé- 
se előtt (és be lehetett tenni a következő gépbe -— ennek jelen- 
tőségét csak az tudja, aki próbált már 5 —30 gépet felhúzni). 
A 3-as fájlban felcsatoltatom a /opt-ba (mert ott úgysincs 
semmi fontos a SystemRescueCD-n) a számomra szükséges 
Samba könyvtárat: 

smbmount //szervergepunk/publ /opt -oguest 


Itt az utolsó opció is kincset ér, mert elkerüli a jelszókérést. 
Végül a 8-as fájl elindítja a partimage-t: 

partimage restore -z1 -b -o /dev/hdaX 

"5 FELCSATOLT. SAMBA KONYVTAR AZ IMAGE FAJLLAL 


Fontos, hogy a restore szó a kapcsolók előtt legyen. 

Aki nem sajnálja a fáradságot, hogy saját igényeihez igazít- 

sa a boot CD-t, az a következőképpen járhat el. 

Másoljuk SystemRescueCD tartalmát egy új könyvtárba. Érde- 
mes talán törölni a , felesleges" részeket (például a dokumen- 

tációt). Így egy bankkártya méretű CD-re is felfér a megmara- 
dó adatmennyiség. Ezután keressük meg az isolinux.cfg fájlt, 


468 


Linuxvilág 


és írjuk át a default sort. Ezzel default myconf lett az eleje, 
amelynek tartalmát a következőképpen definiáljuk: 
label myconf 
kernel vmlinuzi 
append initrd-initrdi acpi-off root-/ 
5 dev/ramO init-/linuxrc setkmap-18 vga-788 
s cdcache ar nowait ar source-//szervergepunk/pub 


A lényeg itt is az ar. source-ban van, ami az autorun for- 
ráshelyére utal. Ez egy hálózati könyvtár, és az itt elhelye- 
zett autorun fájlt (vagy akár többet) végrehajt a CD által 
futtatott Linux azon a gépen, ahol indítottuk! Ez igen ele- 
gáns és rugalmas lehetőség, valljuk meg. 

Az autorun helye persze nemcsak Samba kiszolgáló lehet, 
hanem bármi: USB memória, merevlemez vagy akármilyen 
alkalmas adathordozó. Az itt található autorun parancsfájl- 
ba aztán be lehet , rámolni" mindazt, amit szeretnénk vég- 
rehajtatni. Ezek akár az image fájlban végrehajtott utólagos 
módosítások is lehetnek (például elírtuk a GRLIB menu.lst 
egy sorát, visszamaradt egy postmaster.pid fájl, ami meggá- 
tolja a Postgresgl indítását s emiatt törlendő stb.) 

Nálunk a következő műveletsor futott: 

umount /mnt/cdrom; eject; smbmount //mester/pub 

5 /opt -oguest; partimage restore -z1 -b -o /dev/ 
s5hda6 /opt/img/vect6c; partimage restore -zi -b 
5-o /dev/hda5 /opt/img/uhu5c; mkdir /root/5; 

5 mount /dev/hda5 /root/5; perl -pi -w -e "s/ 

s gfxmenu X(hdo,.0/gfxmenu U(hdo,40/" /root/5/ 
5 boot/grub/menu.]st; grub-install]l --root- 

5 directory-/root/5 /dev/hda; rm -f /root/r/var/ 
5 ]ib/postgres/data/postmaster.pid; umount -a; 

5 reboot 


Az elején, amint lehetett, kidobattam a CD-t, hogy tovább le- 
hessen lépni a következő gépre. Két ilyen CD-vel már vígan 
lehet haladni egy nagyobb gépteremben is. Egy mai számító- 
gépen 3 perc alatt van a cdcache végrehatása (azaz az ideig- 
lenes fájlrendszer memóriába vitele) és az időigényes hotplug 
eszközök vizsgálata. (Ez utóbbi a klónozáskor felesleges, de 
nem sikerült megtalálnom, hogyan lehetne kiküszöbölni 

a futtatását. Érdeklődőbb hackerek negyedére csökkenthetik 
a SystemRescueCD betöltési idejét, ha ezt a lépést kivágják.) 
Mint látható, egyszerre akár több partíciót is feltölthetünk. 
Példánkban az UHU mellett felmásoltam egy VectorLinux 
partíciót is (vect6c). Erről a disztribúcióról már volt szó 

a Linuxvilágban is. Kis gépen is jól fut, és nagyon fÍriss 

a benne található kernel. Érdemes megismerkedni vele 

— hátha anyósunk régi gépére grafikus levelezőprogramot 
kell valaha telepítenünk, és akkor más nemigen jön szóba. 
A saját CD elkészítésére vonatkozó információkat prózai 
módon úgy derítettem ki, hogy mc-ből F3-mal ránéztem az 
iso fájl elejére. Ezt találtam: 

mkisofs -J -R -1] -o ../liveiso.iso -b 
sisolinux/isolinux.bin -c isolinux/boot. cat 

5 -no-emul-boot -boot-load-size 4 -boot-info-table 
5-V Linuxvilag 63 


A SystemRescueCD honlapján (www.sysresccd.org/howto/ 
sysresccd-howto-advanced-customization.php) találunk 
eligazítást arra vonatkozóan is, hogy magát a kernelt 











hogyan lehet újrafordítani, de erre nem volt szükségem. 

A partimage tudja kezelni a MBR-t is (ez szintén betehető 
az autorun fájlba), de én megelégedtem egy GAG telepítésé- 
vel, aminek az az előnye a GRLIB-bal meg LILO-val szem- 
ben, hogy nem árt neki, ha alatta le-föl pakolgatjuk a külön- 
böző Linuxokat. Akkor derült ez ki, amikor egy korábbi 
Linux alatt átszabtam a partíciót, és a GRUIB innentől kezd- 
ve nem látta a neki szánt menu.lst fájlt (és emiatt persze 
más operációs rendszereket se tudott betölteni). 

A GAG telepítéséhez szükséges lépéseknek megfelelő né- 
hány karaktert célszerű egy papírra felírnunk, mert így 30 
másodperc alá lehet szorítani a telepítését, ha nem kell min- 
dig megérteni és kitalálni a következő leütendő billentyűt). 
A ,legalább a Windows menjen, de az automatikusan" vál- 
tozat telepítéshez a következő gombokat kell leütni: 
4-Enter-3-J-S-O-B-win-Enter-Enter-C-B-5-Enter-2-M- 
5 Enter-v 


majd újratöltés vagy kikapcsolás. 

Ha mégis a GRUB mellett maradunk végleges megoldás- 
ként, akkor a klónozást követően (vagy akár autorun-fájlba 
írva, mint fentebb is látszott) érdemes kiadni a 
grub-install] --root-directory- 
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parancsot, ami a MBR-ba írja a — remélhetőleg jól előkészí- 
tett, és a frissen becsatolt fájlrendszer boot/grub/ könyvtárá- 
ban található menu.lst által meghatározott — GRUB-ot. 

(A chroot-tal valamiért nem jártam sikerrel.) Itt érdemes 
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A magyar Línux-barátok magazinja 


Szavazz a CD-mellékletrőlt 


Tavasszal ,Szerkeszd te is a Linuxvilágot!" felhívással egy on-line kérdőív kitöltésére kértük olvasóinkat 
honlapunkon, amelyet örömünkre sokan kítöltöttek, A válaszok több kérdésben meglehetősen 
megosztott véleményt tükröztek, de így is rengeteg hasznos információval szolgáltak nekünk, A 1 
kérdőív értékelését itt találjátok. a 


mindenhol 5] 


megfontolni, hogy ha egy korábbi Linuxunknál más számú 
partícióról indult a GRUB, mint a legutóbbi telepítéskor, ak- 
kor nemcsak a kernel és az initrd szakaszokban levő par- 
tíciószámokat érdemes átírni, hanem a menu.lst elején levő 
gfxmenu (hdx,Y)/boot/themes/uhu 


sorban az X és Y értékeket is, ha azt szeretnénk, hogy meg- 
maradjon a grafikus indítómenünk. Továbblépési lehetősé- 
get jelenthetne, ha , multicast" módban sikerülne letölteni 
a képmás fájlt a szerverről, azaz minden adatcsomag min- 
den géphez eljutna. Ez nyilván felgyorsítaná a klónozást. 
A Linux sokszorosításával az egyik célom az volt, hogy 
megtapasztalhassák a diákok: a legtöbb feladat ugyanúgy 
megoldható nyílt alkalmazásokkal, mint zárt kódú változa- 
tokkal. Azt is ki akartam deríteni, hogy melyek azok az al- 
kalmazások, amelyeket szeretnének használni, de pillanat- 
nyilag nem hozzáférhetők, vagyis hogy a diákok szerint hol 
vannak a Linux gyenge pontjai. Eközben az az életérzés is 
sokat jelentett mindannyiunk számára, hogy egy olyan, 
szabadabb világ építőköveit csiszoljuk, ami nem a pénzre 
épül, hanem , ajándékozó társadalom" paradigmájára, ahol 
az a nagyobb, aki többet ad, többet tesz a közért. 


Szabó Zoltán 

Három gyermekével és feleségével Pannon- 
halmán él. Tíz éve kísérletezik a Linuxszal. 
Matematikát és informatikát tanít, diákotthon- 
ban keseríti a rábízottak életét. Szívügye a PHP 
és a PostgreSOL . (szzOfreemail.hu) 
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Az eredmény alapján készítettünk egy tervezetet a CD-melléketre vonatkozó változtatásokra, 
ennek megvalósításáról a Ti szavazataitok szerint fogunk dönteni. Ezért kérünk mindenkit, hogy 
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Bővítőmodulok segítséggel 


A cikksorozat utolsó részében megvizsgáljuk annak lehetőségét, hogy hogyan 
írhatjuk át saját igényeinknek megfelelően a már elkészült GIMP bővítményeket. 


zésre áll Python nyelven is, így amennyiben megfe- 

lelő kiindulási alapot találunk, apróbb változtatások- 
kal könnyedén hozhatunk létre újabb hatásokat. A meglévő 
bővítményeket tároló könyvtár a GIMP eszköztár ablaká- 
ban a File-: Beállítások párbeszédablakban tekinthető meg. 
Válasszuk ki a bal oldali listában a Mappák-: Bővítmények 
elemeket és nézzük meg a jobb oldali részen megjelenő 
adatokat. Ez a könyvtár az 1-es képen látható esetben 
a /usr/local/tib/gimp/2.0/plug-ins. 
A következő lépés, hogy kiválasztjuk a számunkra megfele- 
lő kiindulási alapot képező bővítményt. A GIMP-ben hoz- 
zunk létre egy új képet vagy nyissunk meg egy már meglé- 
vőt és a Python menüben válasszunk egy modult. Nézzük 
meg, hogy melyiknek az eredménye áll legközelebb az 
elképzeléseinkhez. Az alábbi példában a Clothify modult 
egészítjük ki elképzeléseinknek megfelelően mégpedig 
úgy, hogy a mintázatot színes plazma aláfestéssel tesszük 
látványossá. 
Tekintsük át, milyen változtatásokra van szükség a modul 
regisztrációs részében. Az első listán látható az eredeti 
Clothify modul bejegyzését végző kódrészlet. 


T ekintettel arra, hogy már néhány modul rendelke- 


register( 

"python fu clothify", 

"Make the specified layer look like it is 
sprinted on cloth", 

"Make the specified layer look like it is 
sprinted on cloth", 

"James Henstridge", 

"James Henstridge", 


"1997-1999" , 

" aImages/Python-Fu/Alchemy/. clothify" , 

"RGB", GRAY" , 

L 
(PFLINT, "x blur", "X Blur", 9), 
(PFLINT, "y blur", "Yv Blur", 9), 
(PF.INT, "azimuth", "Azimuth7", 135), 
(PF.INT, felevation", "felevation", 45), 
(PF.INT, "depth", "Depth", 3) 

1: 

8 


python clothify) 
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1. ábra A bővítményeket tároló könyvtár 


Számunkra tulajdonképpen csak a párbeszédablak felépí- 
téséhez szükséges változók definíciója érdekes, amelyet 

a (PF . kezdetű sorokban határozott meg a bővítmény 
készítője. 

A kiegészítésünkhöz még két változóra lesz szükség. 

Az egyik a plazma hatás örvénylésének mértékét adja 
majd meg, míg a másik a létrejövő rétegek átlátszatlansá- 
gát. Az átlátszatlansággal tudjuk majd befolyásolni, hogy 
milyen mértékben érvényesül a mintázat és mennyiben 
marad meg az eredeti hátteret képező kép. Az örvénylés 
meghatározására szolgáló változó neve legyen turbulence, 
típusa lebegőpontos. Az átlátszatlanság meghatározását 
egy csúszka segítségével végezzük, melynek értéke nullá- 
tól százig változhat. A programban majd lebegőpontos ér- 
tékként használjuk, de a bejegyzést végző kódrészletnél 
ennek nincs jelentősége. A változónk neve legyen opacity. 
A második listán látható sorokat írjuk tehát az eredeti kód- 
ban a szögletes zárójel bezárása elé, de ne felejtsük el az 
eredetiben a sor végén vesszővel jelezni a Python értelme- 
ző számára a folytatást. 

Látható az eredeti részletben, hogy a menüben hol helyez- 
kedik majd el a bővítmény. Ezt a sort is javítsuk ki valami- 
lyen más névre. Jelen esetben a Python-Fu-: Alchemy-: 
Plasma Clothify nevet választottam. A modul fő eljárásának 
a nevét is megváltoztattam, így a bejegyzést végző register 
eljárásban is az utolsó paraméterben a megváltozott nevet 
kell megadni. A 2-es listán látható a kódrészlet a leírt vál- 
toztatások elvégzése után. Az első paraméterben megadott 
nevet is ki kell cserélnünk valamilyen más azonosítóra, 














2. ábra Az eredeti bővítmény 


hiszen a GIMP ezen név alapján tárolja a saját bővítmény- 
adatbázisában az új eljárást. A bővítmény neve az új válto- 
zatban python fu plasmaclothify lesz. 


ft eredeti részlet 
(PFLINT, felevation", 
(PFLINT, "depth", "Depth", 


"elevation", 45), 
3) , 


ft örvénylő hatás beállítására 
(PF. FLOAT, "turbulence", "Plasma turbulence", 
90.5), 
ft rétegek átlátszatlansága (alapértelmezés 202) 
(PF. SLIDER, "opacity", "Layers opacity", 20, 
(0, 100, 19) 

1, 

[1 , 

python pclothify) 


A változók és a párbeszédablak beállítása után következhet 
az érdemi munka. 

Lényegében a változtatás annyiból áll majd, hogy még egy 
plusz réteget adunk a képhez, melyen a plazma hatást lét- 
rehozzuk. A hatások elkészítése után a rétegeket a képre 
lapítjuk, így érjük el a végleges eredményt. Az eredeti bő- 
vítménnyel ellentétben most nem egy új képet hozunk létre 
hanem a GIMP által átadott képen dolgozunk. Az eredeti 
modulban minden műveletet az img változó által tárolt ké- 
pen hajtunk végre. Első dolgunk tehát az legyen, hogy ahol 
hivatkozást találunk erre a változóra, azokon a helyeken ja- 
vítsuk ki timg névre a megadott változót. Hogy miért pont 
timg-re? Ha jobban megvizsgáljuk a bővítmény fő eljárását, 
észre fogjuk venni, hogy az első paraméter neve timg. Ez az 
a változó, melyben a GIMP átadja a modul részére a feldol- 
gozásra szánt képet. Tehát a kívánt eredmény elérése érde- 
kében nekünk a program által adott képen kell dolgoz- 
nunk, vagyis azon, melyet a timg változóban kapunk. 
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Ezután az alapvető változtatás után már tulajdonkép- 

pen nincsen sok dolgunk. A plazma hatást a GIMP bő- 
vítményei között találjuk, tehát az alábbi lépésekben össze- 
foglalható minden szükséges változtatás. Elsősorban, miu- 
tán az eredeti változat szerint elkészült a két ruhaszerű 
mintázatot megjelenítő réteg, következhet a harmadik réteg 
létrehozása. A harmadik rétegen jelenik meg a plazma ha- 
tás. Hozzunk létre egy új réteget a képen a gimp.LayerO 
objektum elkészítésével. Itt már a létrehozásnál adjuk meg 
a felhasználó által beállított átlátszatlanság értéket az 
opacity változó segítségével. Mivel a gimp.Layer() objek- 
tum létrehozásakor a hatodik paraméter az átlátszatlanság, 
így nincsen nehéz dolgunk. Az új réteg megjelenítési mód- 
ja legyen HARDLIGHT. MODE, hogy jobban láthatóvá váljon 

a plazma mintázat a modul futtatása után. A példában 
használt réteget tároló változó a layer alma nevet kapta. 
A réteg létrehozása után következhet a plazma hatás elké- 
szítése. A GIMP-ben minden bővítményt vagy eljárást elér- 
hetünk más bővítményekből is, tehát a nyugodtan meghív- 
hatjuk a pdb.plug in plasmaO eljárást. Az eljárás négy 
paramétert vár. Az első legyen a kép, melyhez az új réteg 
tartozik. Ez jelen esetben megegyezik a GIMP által átadott 
timg képpel. A második paraméter az a réteg, melyen 

a plazma hatás megjelenik. Példánkban ez a layer alma 
réteg. A harmadik paraméter a véletlenszámok létrehozásá- 
hoz használandó alapérték. A bővítmény elején olvassuk be 
a Python rutinok között található time gyűjteményt, mely- 
ben megtalálható a timeO függvény. Az éppen aktuális idő 
elegendő véletlenszerűséget biztosít a plazma hatás elkészí- 
téséhez, tehát nyugodt szívvel használhatjuk az eljárás har- 
madik paramétereként. A negyedik szükséges paraméter 
határozza meg a hatás szabálytalanságát. Ez utóbbi értéket 
korábban örvénylésnek neveztük és a modul beállítására 
szolgáló ablakban a felhasználó állítja be. 

Az új réteget természetesen az eredeti képhez is hozzá kell 
adni, erre szolgál a timg.add layerO függvény. 

Az utolsó lépésben már csak annyi a teendő, hogy a képen 
lévő rétegeket a timg. flattenO eljárás meghívásával egy 
réteggé ,lapítjuk". Végeredményben ez a pár lépés elegen- 
dő lenne a kívánt eredmény eléréséhez, azonban néhány 
apróbb módosításra még szükségünk van. 

Elsősorban arról van szó, hogy az eredeti modulban a hoz- 
záadott rétegek egyáltalán nem átlátszóak. Ez számunkra 
nem túl sikeres választás, hiszen ebben az esetben a háttér- 
ként szolgáló kiindulási képet már az első hozzáadott réteg 
teljesen el fogja takarni. A megoldást jelentő változtatás az 
első réteg létrehozására használt gimp.Layer() hívás jelen- 
ti. Ha megvizsgáljuk ennek az eljárásnak a paramétereit 
látható, hogy a hatodik paraméter — az átlátszatlanság mér- 
téke -—, állandó 100-as értéket kap. Ahogyan az általunk lét- 
rehozott rétegnél megoldottuk, itt is ki kell javítani ezt az 
állandót a felhasználó által beállított értékre. Cseréljük ki 
tehát a megadott értéket az opacity változóra. 

A második rétegnél szintén hasonló problémába ütközhe- 
tünk, azonban nem találunk az első réteg létrehozásához 
hasonló hívást. Tulajdonképpen a második réteg az első 
másolataként jön létre, amit láthatunk a layer two - 
layer. one. copyO sorban. A második rétegnél különféle 
változókat is beállítunk, mint például a layer. two.mode - 
MULTIPLY. MODE sorban. Itt állíthatjuk be az átlátszatlanságot 
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3. ábra Az új modul eredménye 


is, arra azonban vigyázni kell, hogy a rétegnek lebegő- 
pontos számot kell megadnunk. A layer two. opacity - 
floatCopacity / 100) sorban végezzük el ezt a beállítást. 
Utolsó lépés, hogy az első réteg megjelenítési módját 
(hetedik paraméter a gimp. Layer hívásnál) szintén 
MULTIPLY. MODE-ként határozzuk meg, így jobban kiemeljük 
a végeredményben a réteg hatását. 

Mivel csak a harmadik réteg elkészítése után van szüksé- 
günk a rétegek összevonására, az eredeti kódban szereplő 
timg.flattenO hívásokat megjegyzésbe tettem. Természe- 
tesen ki is lehet törölni ezeket a sorokat, de az érthetőség 
és a változtatások követése szempontjából érdemes a meg- 
jegyzést használni. Így később is tudjuk majd, milyen vál- 
toztatásokat végeztünk a programban és nem veszítjük 
szem elől a bővítmény lényegét alkotó sorokat. 

A harmadik listán látható a teljes bővítmény listája a koráb- 
ban már tárgyalt bejegyzést elvégző register hívás nélkül. 
A második képen az eredeti modul által előállított képet 
tekinthetjük meg. A hármas képen az új változat által készí- 
tett képet vehetjük szemügyre. 


$1!/usr/bin/env python 


import time 
import math 
from gimpfu import " 


def python pclothify(timg, tdrawable, bx-9, by-9, 
azimuth-135, elevation-45, depth-3, 
turbulence-0.5, opacity-20): 
bx - 9 ; by - 9 ; azimuth -— 135 
elevation - 45 ; depth — 3 
width - tdrawable.width 
height - tdrawable.height 


ft eredetileg új képen dolgozott a bővítmény. 


32 
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t nekünk mindent az aktuális képen kell elvégezni 
tf img - gimp.Image(width, height, RGB) 


ft atlatszóság beállítása a megadott 

ft értékre és szorzás mód 
layer one - gimp.Layer(timg, "X Dots", width, 
height, RGB IMAGE, 
opacity, MULTIPLY MODE) 
timg.disable undoO 
pdb.gimp. edit fill(Iayer one, BACKGROUND. FILL) 
timg.add layer(layer one, 0) 
pdb.plug in noisify(timg, layer one, 

05.707, -0.72470.7) 

layer two - layer one.copyO 
layer two.mode -— MULTIPLY MODE 


ft beállítjuk az átlátszóságot 
layer two.opacity - float(opacity / 100) 


layer two.name — "Y Dots" 
timg.add layer(layer two, 1) 
pdb.plug in gauss rle(timg, layer one, bx, 
1, 0) 
pdb.plug in gauss rle(timg, layer two, by, 
0; 1 
ít erre nincs szükség 
ht img.flattenO 
bump. layer - timg.active layer 
pdb.plug in c astretch(timg, bump. layer) 
pdb.plug in noisify(timg, bump layer, 
0, 0.2, 0.2, 0.2, 0.2) 
pdb.plug in bump. map(timg, tdrawable, 
bump. layer, azimuth, 
elevation, depth, 0, 0, 
0, 0, TRUE, FALSE, 0) 


ft új réteg és a plazma bővitmény használata 
layer alma - gimp.Layer(timg, "Plasma" , 
width, height, RGB IMAGE, 
opacity, HARDLIGHT. MODE) 
pdb.plug in plasma(timg, layer alma, 
int(time.timeO)), turbulence) 
ft réteget hozzáadjuk a képhez 
timg.add layer(layer alma, 1) 
tt kép végső lapítása 
timg.flattenO 


ft az új képet nem használtuk, 
ft így törölni sem kell 
ft gimp.delete(Cimg) 


Gyakorlatilag ez utóbbi tíz hónap alatt megtárgyaltunk 
minden olyan fontosabb dolgot, amire a GIMP-ben lehe- 
tőségünk adódik, így a sorozatnak nincsen hivatalos folyta- 
tása. Természetesen otthon vagy munkahelyén mindenki 
tovább folytathatja az ismeretek alkalmazását és bővítését, 
ebben a továbbiakban elektronikus levelezés útján a szerző 
is szívesen nyújt segítséget. 


Fábián Zoltán 











Védekezés levélkiszolgáló túlterhelése ellen 


Egy győri szakközépiskola tanár-rendszergazdájaként linuxos kiszolgálókat üzemel- 
tetek. A múlt év végétől, egyre gyakrabban tapasztaltuk azt a hibajelenséget, hogy 


a munkaállomásokon működő ügyfélprogramok hosszasan próbálkoztak egy-egy 
e-mail elküldésével, majd , Kapcsolat megszakadt" hibaüzenettel leálltak... 


ivel eddig nem tapasztaltam ilyen rendellenes- 
út] séget, több dologra is gyanakodtam. Végül le- 

vélkiszolgálónk forgalmának és terheltségének 
elemzésével világossá vált a valódi ok, és hamarosan a meg- 
oldást is sikerült megtalálnom. 
A levelező kiszolgálónkon Debian Linux alatt Postfix MTA 
üzemel, amely a /var/log/mail.1og fájlba naplóz. A naplóbe- 
jegyzéseket root-ként egyszerűen a Midnight Commander 
segítségével néztem meg. Itt csak 4 jellegzetes sort mutatok 
meg, amelyek egyetlen küldési kísérlethez tartoznak. 
Kiderült, hogy kiszolgálónkhoz gyors egymásutánban több 
IP-ről nagyszámú e-mail érkezett, mégpedig ismeretlen fel- 
használók címére. Ahogy a 3. sorban látható, az ismeretlen 
felhasználónak küldött levél a 450-es számú User unknown 
hibaüzenetet váltja ki és a bejegyzésbe a reject (elutasítva) 
kifejezés kerül: 


1: Feb 6 06:51:22 mail postfix/smtpd[173991] : 
sconnect from 

5Smx6a.uniserve.ca[216.113.192.921] 

2: Feb 6 06:51:23 mail postfix/smtpd[173991] : 
SO6616662CA: 
sclient-mx6a.uniserve.ca[216.113.192.92] 

3: Feb 6 06:51:23 mail postfix/smtpd[17399]: 
sreject: RCPT from 
Smx6a.uniserve.ca[216.113.192.92]: 450 

5 cestela.rudolpho8€pattantyus-gyor.sulinet.huz: 
suúser unknown; from-cs 
5to-cestela.rudolph6ő84pattantyus-gyor. sulinet . huz 
4: Feb 6 06:51:28 mail postfix/smtpd[173991]: 
sdisconnect from mx6a.uniserve.ca[216.113.192.92] 


A Postfix csak akkor utasítja el az ismeretlen felhasználók- 
nak küldött leveleket, ha megfelelően van beállítva. Ehhez 
az /etc/postfix/main.cf fájlban, a következő soroknak kell 
szerepelni: 


1: alias maps - hash:/etc/aliases 

2: alias database - hash:/etc/aliases 
3: local recipient maps - $alias maps 
snis:passwd.byname 
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1. ábra Az iskola hálózatának felépítése 


Az 1. és 2. sor az alias fájlok helyét adja meg. Ha például 
valakinek horvath! a felhasználói neve, de 

a horvath. laszlotdomain címmel szeretne levelezni, akkor 
ezt az alias fájlban kell megadni. Azt is itt lehet megadni, 
hogy a titkarsag(domain címre küldött e-mail melyik fel- 
használónak, vagy felhasználóknak a postafiókjába kerüljön. 
A 3. sor arra utasítja a Postfixet, hogy csak azon felhaszná- 
lók címére fogadjon el e-mailt, akik vagy szerepelnek az 
alias-ban, vagy a NIS adatbázisban léteznek (a kiszolgálóin- 
kon jelenleg NIS azonosítás működik). 

Az elutasításnak természetesen más okai is lehetnek. 

Ha például a küldő IP-nek nincs DNS-bejegyzése, vagy 

ha továbbítónak (relay) akarja használni a kiszolgálónkat. 
Ilyenkor persze másféle hibaüzenetek keletkeznek. 

Először arra gyanakodtam, hogy a rengeteg téves próbál- 
kozás valamilyen e-mail küldő vírus tevékenységének 

a nyoma. A következő módon megvizsgált levelek tartalma 
azonban azt bizonyította, hogy valójában reklámküldési kí- 
sérletekről van szó. A /etc/postfix/main.cf fájlon a következő 
változásokat hajtottam végre: 


1: local recipient maps - 
snis:passwd.byname 

2: luser relay -— 

s felhasznalonevApattantyus-gyor.sulinet.hu 


$alias maps 


Az 1. sor a postafiók meglétének ellenőrzését kikapcsolja 
(megjegyzésjelet tettem a sor elejére). A 2. sor hatására 
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a rendszer az ismeretlen felhasználóknak küldött leveleket 
az itt megadott postafiókba továbbítja. 

A módosítás után a Postfixet újra kell indítani: 
/etc/init.d/postfix restart 


Vigyázat!!! Ha valahova olyan sok reklámlevél érkezik mint 
a mi címünkre, rövid idő alatt is rengeteg e-mail kerülhet 

a megadott fiókba. Ezért néhány perc után a /etc/postfix/ 
main.cf fájlt helyreállítva a Postfixet újra kell indítani. 


A kiszolgáló forgalmi statisztikája 

és terheltségének vizsgálata 

A napló tartalmának megismerése után kíváncsi voltam 

a szerver forgalmára. A Postfix esetében ehhez csak 

a pflogsumm csomagot kell telepíteni. Statisztika készítése 
a naplófájlban lévő valamennyi nap adataival: 
pflogsumm.pl /var/log/mail.log 5 /root/statisztika 


Csak az aktuális napi forgalom statisztikája: 
pflogsumm.pl -d today /var/log/mail.log 
5 /root/statisztika 


A today helyett yesterday-t írva pedig az előző napi forga- 
lom statisztikáját készíti el. 

Az elkészített statisztikából látszik, hogy egy nap alatt 40483 
e-mailt fogadott (received), s ebből mindössze 591-et to- 
vábbított (delivered), 40028-at pedig elutasított (rejected): 


Postfix log summaries for Feb 6 


Grand Totals 


messages 
40483 received 
591 delivered 


1  forwarded 
11 deferred (33 deferrals) 
0) bounced 

40028  rejected 


Lejjebb látható, hogy miért, illetve melyik küldőtől hány 
e-mailt utasított el a rendszer. Ebből az derült ki, hogy az el- 
utasítások túlnyomó többsége azért történt, mert ismeretlen 
felhasználónak (user unknown) címezték a levelet. 


message reject detail 
RCPT 
Sender address rejected: Access denied 
26 — spamblocker- 
5 challengedbounce. earthlink.net 
14 — molnarlouisíbellsouth.net 
13 ErnoHokadaol. com 
Sender address rejected: Domain not found 
20 — Antivirusíaxxis.local 
14 Symantec Mail Security for. 
55 SMTPGMSL . COM 
3  — MAILER-DAEMON(gcs . gateway 
admin(system.mai1 
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user unknown 


437 cox.net 

256 rr.com 

244 — swip.net 

199 — siteprotect.com 
154  netvigator.com 


Ha a levelezőkiszolgáló elutasítja a nemkívánatos e-maile- 
ket, akkor miért terhelődik túl? A Postfix az internetről és 

a belső hálózatról is, az smtpd programjával fogadja az 
e-maileket, amely alapértelmezés szerint egyszerre legfel- 
jebb 50 kapcsolatot tud kezelni. A Postfix 2.2-es változata 
óta lehetőség van ennek az értéknek a megemelésére, 

de a hardver gyorsasága és főleg a sávszélesség által szabott 
korlátok miatt nem biztos hogy ez célszerű. 

Az adott pillanatban élő smtpd-kapcsolatok számát a követ- 
kező paranccsal néztem meg: 

ps ax I] grep smtpd I] wc -1 


Ennek értéke a fent bemutatott terheltség mellett legtöbbször 
50 volt így nem tudott új kapcsolatot felépíteni a Postfix. A le- 
velező ügyfelek meghatározott ideig próbálkoztak, majd idő- 
túllépés miatt írták ki a , Kapcsolat megszakadt" hibaüzenetet. 


A bejövő smtp kapcsolatok időben történő korlátozása 
Az első ötletem az volt, hogy csomagszűrő segítségével 
korlátozom az internet felől felépíthető kapcsolatok számát 
a levélkiszolgáló felé. Mivel intézményünkben a levelező 
kiszolgáló tűzfal mögött működik, a tűzfalgép szűrési sza- 
bályaiba építettem be a korlátozást: 


:  eth kulso-"eth07 
2:  IPTABLES-/sbin/iptables 


$IPTABLES -t nat -N pre smtp 

5:  $IPTABLES -t nat -A pre smtp -m limit --Tlimit 
520/minute -j RETURN 

6: $IPTABLES -t nat -A pre smtp -j DROP 

7:  $IPTABLES -t nat -A PREROUTING -i $eth kulso 
5-d 195.199.100.200 -p tcp --dport smtp --syn 
5-j pre smtp 


9: $IPTABLES -t nat -A PREROUTING -p tcp -d 
5195.199.100.200 --dport smtp -j DNAT --to 
5192.168.0.4:25 

10: $IPTABLES -t nat -A POSTROUTING -p tcp -s 
5192.168.0.4 --sport smtp -j SNAT --to 
596195.199.100.200:25 


Itt a tűzfal külső (internetre csatlakozó) hálózati kártyájá- 
nak IP címe 195.199.100.200, míg a levélkiszolgáló címe 
192.168.0.4. 


A beállítások jelentése a következő: 
1. sor: A tűzfalgép külső (internetre csatlakozó) ethernet 
kártyájának megadása. 


ne kelljen mindig megadni. 











4. sor: Új pre. smtp nevű lánc létrehozása 

5. sor: Ha a kapcsolatok száma nem több percenként 
20-nál, akkor visszatér a láncból, vagyis elfogadja 

(az értéket kísérletileg kell megállapítani, a szerver 
feldolgozóképességétől függ) 

6. sor: Ha az előbbi sorban megadottnál több kapcsolat 
akar felépülni, akkor eldobja azokat. 

7. sor: Ha a külső kártyán keresztül (internet felől) a tűz- 
falgép külső IP címére a TCP protokollon a 25-ös (smtp) 
portra kapcsolatteremtő csomag érkezik, ugrás a létre- 
hozott pre smtp láncra 

9. sor: Ha TCP protokollon a tűzfal gép külső címén 

a 25-ös (smtp) portra érkezik csomag, átirányítja a leve- 
lező szerverre. 

10. sor: Ha TCP protokollon a levelező szerver 25-ös 
(smtp) portjáról érkezik csomag, átirányítja a tűzfal gép 
külső kártyájára. 


A fenti pár soros szkriptet természetesen módosítani kell, 
ha a levélkiszolgáló közvetlenül csatlakozik az internetre. 
Ekkor a -t nat részeket el kell hagyni, a PREROUTING be- 
jegyzést INPUT-ra kell cserélni, a 9. és 10. sorok pedig termé- 
szetesen elmaradnak. 

A fenti korlátozás csökkentette a terhelést, a belső levelezést 
zavartalanná tette, de sajnos a kívülről érkező legális levele- 
ket is várakozásra kényszerítette és időtúllépés miatt nem 
mindegyik jutott el a címzetthez. Olyan megoldást kellett 
ezért keresnem, ami lehetőleg csak a kéretlen levelek kül- 
dőit korlátozza. 


Az , ellenséges" IP címek szelektív tiltása 

Ötletem a következő volt. A levélkiszolgáló naplóállományát 
periodikusan átvizsgálva, ki lehet keresni azokat a címeket, 
melyekről megadott számú elutasított e-mail érkezik egy 
megadott idő alatt és ezeket egy szintén megadott időre 

ki kell tiltani. Természetesen nem lehet örök időre kitiltani 
egyetlen IP címet sem és nem is érdemes, hiszen az IP-k vál- 
toznak. Azt is figyelembe kellett vennem, hogy olyan címek 
ne legyenek kitiltva, ahonnan hivatalos levél is érkezhet. 

A kitiltásokat és engedélyezéseket naplózni kell, hogy bár- 
mikor meg lehessen nézni a tiltásokat és engedélyezéseket. 
A feladat megoldására héjprogramot készítettem, mely a til- 
tást csomagszűréssel valósítja meg. Gondolom néhányan 
csóválják a fejüket, miért nem Perl-ben vagy esetleg C-ben 
írtam. Eredetileg az egyszerűség miatt döntöttem a héj- 
program mellett, a gyakorlat azonban bebizonyította, hogy 
a héj és a különböző szűrőparancsok minden szükséges 
eszközt biztosítanak egy ilyen feladat hatékony megoldásá- 
hoz. Itt csak az érdekesebb sorokat mutatom be. A teljes 
program letölthető a Linuxvilág magazin webhelyéről 
(http:[/www.linuxvilag.hu). 


1: £!/bin/sh 
5: $ Keszitette: Jaszberenyi Jozsef, 2005 


21: MAX REJECT-10 
24: TILTOTT. ORAK-36 
27: MAX L0G-5000 


30: LOGFAJL-"/var/1og/mai1 . 1097 
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33: TILTOTTIPDIR-"/var/log/ipdisable" 

36: TILTOTTIPFAJL-"tiltottIP.1og" 

39: NAPLO-"naplo.1log" 

42: NEMTILTHATOIP-"nemtilthatoIP" 

45: TILTOTTIPFAJL-"$TILTOTTIPDIR/$TILTOTTIPFAJL" 
46: NAPLO-"$TILTOTTIPDIR/$NAPLO" 

47: NEMTILTHATOIP-"$TILTOTTIPDIR/ $NEMTILTHATOIP" 


50: ECHO-/bin/echo 
51: [ -x $EcHo ] II exit 5 


126: trap "$RM -f /tmp/$$ ?.tmp; exit 2712391 


129: 
130: 
131: 
132: 
1335 


TMP1-"/tmp/$$ 1. tmp" 
TMP2-"/tmp/$$. 2. tmp" 

TMP. DOMAIN-"/tmp/$$. 3.tmp" 
TMP. IPCIM-" /tmp/$$. 4 . tmp" 
TMP. TILTANDO-—" /tmp/$$. 5 . tmp" 


137: 
138: 
139: 
140: 
141: fi 


if ! [ -f $NEMTILTHATOIP ] 

then 
$ECHO "Nem talalom a $NEMTILTHATOIP fajl-t!" 
exit 5 


153: 
154: 
155: 
156: fi 


if ! [ -f $TILTOTTIPFAJL ] 
then 
$TOUCH $TILTOTTIPFAJL 


162: HONAP-  $DATE --6b" 

163: HONAPOK- $ECHO $HONAP ] $cuT -c 1 ] $TR a-z A-Z" 
164: HONAPOK-$HONAPOK $ECHO $HONAP ] $CUT -c 2- ] $TR 
53A-Z a-z 

167: NAP- $DATE 49e ] $TR -d " "/ 

170: TILTASI IDO-$[ $DATE -26s5 / 3600] 


177: NAPLOARCHIV-$NAPLO.tgz 
180: if [ -f $NAPLO ] 


181: then 

183: — MAX LOG-$[$MAX LOG " 10241] 

185: — FILEMERET- $LS -1] $NAPLO I] $AwK " fprint $53 "7 
187: — if [ $FILEMERET -ge $MAX LOG ] 

188: then 

190: $RM -f $NAPLOARCHIV 

192: $TAR cfz $NAPLOARCHIV $NAPLO 

194: $RM -f $NAPLO 

195: fi 

196: fi 

201: $ECHO "4t-——-————————————————————— " ss $NAPLO 


202: $ECHO "Start: " $DATE 535 $NAPLO 


204: f Kigyujti az aktualis napon keletkezett, 
s "reject:" kifejezest tartalmazo sorokat 9. mezojet 
207: $GREP "reject:" $LOGFAJL ] $AWK -v H-$HONAPOK -v 
SN-$NAP "$1 - H €d $2 - N íprint $9)7" 5 $TMP1 


209: f Kigyujti a domain neveket egy kulon listaba 
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210: $AWwK -F[ "íprint $1)" $TMP1 5 $TMP DOMAIN 


212: f Kigyujti az IP cimeket egy kulon listaba 
215: $SED s/A.MUI// c $TMP1 I] $SED s/]."$// 5 
5 $TMP. IPCIM 


217: f Elollitja az uj listat soronkent egy IP-cim, 
5majd szokozzel a domain nev 
218: $PASTE $TMP. IPCIM $TMP DOMAIN 5 $TMP1l 


220: 4 Eltavolitja a nem tilthato IP-ket 
221: for cím in $CAT $NEMTILTHATOIP" 
222: do 

223: 
224: 
2253 


$GREP -v A$cim $TMP1 5 $TMP2 
$CP -f $TMP2 $TMP1l 
done 


227: 4 Sorba rendezi a sorokat IP szerint es meg- 
sSszamolja melyik IP hanyszor fordult elo a listaban 
228: $SORT c $TMP1 ] $UNIOG -c 3 $TMP2 


230: í Kivalogatja azokat az IP-ket, melyekrol a meg- 
ssadott szamot 

231: 4 meghalado elutasiítas tortent es kiirja 

sa tiltando IP-ket tarolo fajlba 

232: $AWK -v DARAB-$MAX REJECT "$15-DARAB íprint 
59$27:"$3)" c $TMP2 5 $TMP. TILTANDO 


235: 4 kitiltja a tiltando cimeket ha nem szerepelnek 
meg a tiltottIP fajlban 

236: 4 es listazza a tiltottIP fajlba idobelyeggel es 
sdomain nevvel egyutt. 

239: for sor in cat $TMP TILTANDO ; do 


240: cim- $ECHO $sor ] $AWK -F: " ífprint $1k "7 
241: domain- $ECHO $sor I $AwK -F: " ífprint $23 "7 
242: if ! $GREP -s $cim $TILTOTTIPFAJL 55 


5 /dev/null 2581 

243: then 

244: $IPTABLES -I INPUT -i eth0 -p tcp --dport 
Ssmtp -s $cim/32 -j REJECT 


245: $ECHO -n $cim 55 $TILTOTTIPFAJL 

246: $ECHO -n : 55 $TILTOTTIPFAJL 

247: $ECHO -n $TILTASI IDO 35 $TILTOTTIPFAJL 
248: $ECHO -n : 55 $TILTOTTIPFAJL 

249: $ECHO $domain 5353 $TILTOTTIPFAJL 

250: $ECHO "Tiltva:  $cim $domain" ss $NAPLO 
251: fi 

252: done 


255: 4 Ha van olyan IP a tiltottIP fajlban ami a meg- 
ssadott idonel regebben lett tiltva, 

256: £ akkor torli a tiltast, torli a tiltottIP 
sfajlbol a bejegyzest es naplozza 

258: for sor in cat $TILTOTTIPFAJL ; do 


259: íf kulonvalasztja a mezoket 

260: cim- $ECHO $sor ] $AWK -F: " ífprint $1 "7 

261: ERTEK- $ECHO $sor ] $AWK -F: " ífprint $23 "7 

262: domain- $ECHO $sor ] $AwK -F: " ífprint $33 "7 
263: 

264: if [ $ERTEK -]le $[($TILTASI IDO-$TILTOTT. ORAK] ] 
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265: then 
266: $IPTABLES -D INPUT -i eth0 -p tcp --dport 
S smtp -s $cim/32 -j REJECT 


267: $GREP -v $sor $TILTOTTIPFAJL 5 $TMP1l 
268: $MV -f $TMP1 $TILTOTTIPFAJL 

269: $ECHO "Engedelyezve: $cim $domain" 35 $NAPLO 
270: fi 

271: done 

274: $RM -f /tmp/$$ ?.tmp 

276: $Script futas befejezesi idopontjanak naplozasa 
277: $ECHO "End: "" $DATE 353 $NAPLO 

278: $ECHO 

280: exit 0 


A programfájlt természetesen futtathatóvá kell tenni: 
chmod 755 ipdisable 


Elemzés 

: . A 21. sorban adjuk meg, hány elutasított e-mail után tiltjuk 
ki a küldő IP címét. Ezt az értéket kísérletileg kell meghatá- 
rozni a terheltség függvényében. A program alapértelme- 
zésként csak az aznapi bejegyzéseket vizsgálja. 
A 24. sor tartalmazza, hogy hány órára lesz kitiltva az 
IP cím. Célszerű ezt az értéket 24-nél nagyobbra állítani, 
mert az elutasított e-mailek jelentős része nem levélki- 
szolgálón keresztül érkezik, hanem közvetlenül 
internetre csatlakozott gépekről, melyek IP címe általá- 
ban 24 óra után változik meg (a szolgáltató bontja 
a kapcsolatot és új IP-t oszt ki) 
A 27. sorban a naplófájl legnagyobb méretét adjuk meg 
(KB-ban), míg a 30-47 sorok bizonyos elérési utakat és 
fájlneveket adnak meg. 
A nemtilthatoIP nevű fájlban (42. sor) kell megadni 
azokat az IP címeket, illetve tartományokat, melyeket 
a programnak soha nem szabad kitiltania. Itt mindenek 
előtt célszerű megadni a belső hálózat IP tartományát. 
A fájlban megadható teljes IP cím (193.233.21.14), 
vagy IP tartomány is (10.0.). 
Az 50-123 sorokban megadjuk bizonyos UNIX paran- 
sor felhasználói megszakítás, vagy a gép újraindulása 
esetén gondoskodik az átmeneti fájlok törléséről, ame- 
lyek helyét a 129-133 sorokban adjuk meg. 
A 137-156 sorokban egyes fájlok meglétét ellenőrizzük. 
A nemtilthatoIp fájlnak létezni kell a TILTOTTIPDIR 
változóban megadott könyvtárban, különben a program 
futása befejeződik. A többi fájlt a program létrehozza, 
ha még nem léteznek. 
162-164 sorokban az aktuális dátum hónap nevét 
kérdezzük le, majd konvertáljuk ugyan olyan formá- 
tumra, mint ahogy a Postfix naplófájlban szerepel. 
A 167. sorban a dátum napját kérdezzük le és töröl- 
jük a felesleges szóközt, ami egyjegyű szám esetén 
szükséges. 
170. sorban időbélyeget állítunk elő 1 órás felbontással. 
Az időbélyeg segítségével tudjuk megállapítani, mennyi 
idő óta van egy IP kitiltva. 











177-196 sorokban a naplófájl maximális méretét korlá- 
tozzuk. Ha van naplófájl és a hossza eléri a megadott 
max. méretet, akkor tömörítjük, majd töröljük a már 
betömörített eredeti naplót. Ha volt már betömörített 
naplófájl, akkor azt töröljük. 

201-202 sorokban kezdjük a naplózást, a program futás 
kezdeti időpontjának kiírásával. 

207. sorban a Postfix naplófájlból kigyűjtjük egy átme- 
neti fájlba az aktuális napon keletkezett, reject: kifeje- 
zést tartalmazó soroknak a 9. mezőjét. Az átmeneti fájl- 
ban a domain után szögletes zárójelek között lesz az IP 
cím. Ennek a formátumnak a kezelése nem lenne egy- 
szerű, ezért át kell alakítani. 

210-218 sorokban olyan formátumú fájlt hozunk lét- 
re, melyet a későbbiekben könnyen tudunk feldol- 
gozni. A fájl minden sorában egy IP címet írunk, 
majd szóközzel a hozzátartozó domaint. A 210. sor- 
banlétrehozzuk a domaineket tartalmazó ideiglenes 
fájlt. Mivel a domain után szóköz nélkül egy kezdő 
szögletes zárójel van, az avk programmal könnyen 
szét tudjuk választani az utána lévőktől. A 215. sor- 
ban az IP-ket tartalmazó ideiglenes fájlt hozzuk lét- 
reolyan módon, hogy sed parancs segítségével töröl- 
jük a szögletes zárójelek előtti és utáni karaktereket, 
beleértve a zárójeleket is. A 218. sorban egyesítjük 

az IP-ket és a domaineket tartalmazó fájlokat. 
221-225 sorokban töröljük a fájlból a nem tiltható 
IP-ket olyan módon, hogy csak azokat a sorokat 
másoljuk át, melyek nem úgy kezdődnek, mint 

a nemtilthatoIP sorai. 

228. sorban megszámoljuk, hogy melyik sor hányszor 
fordul elő. A rendezésre azért van szűkség, mert az 
unig csak így működik helyesen. 

232. sorban kiválogatjuk azokat a sorokat, melyek leg- 
alább megadott darabszámban fordulnak elő. Ezeket az 
IP-ket fogjuk kitiltani, ha eddig nem lettek (nem szere- 
pelnek még a tiltottIP. 1og fájlban). 

239-252 sorokban tiltjuk ki az , ellenséges" IP-ket: 
ehhez sorra vesszük a kitiltandó IP-ket és ha még nin- 
csenek kitiltva, akkor kitiltjuk azokat. A tiltást naplóz- 
zuk a tiltottIP. 1og fájlba ,IP:időbélyeg:domain" 
formában, valamint a naplo. 10g fájlba. A 242. sor 
végére azért írtam a 55 /dev/nul1 2581 részt, mert 
különben a grep kimenetéről minden futás után 
e-mailt küld. 

258-271 sorokban engedélyezzük azokat az IP-ket, 
melyek már elég ideig voltak tiltva. Az engedélyezett 
IP bejegyzését töröljük a ti ltottIP . 1og fájlból és az 
engedélyezést naplózzuk a naplo. 109 fájlba. 

274. sorban töröljük az ideiglenes fájlokat. 

277-278 sorokban fejezzük be a naplózást. A prog- 
ram futásának befejezési idejét a naplo. 1og fájlba 
írjuk. 


Időzítés és a működés ellenőrzése 

A programot rendszeres időközönként kell futtatni, mi- 
vel óránként jelentkeznek újabb kalóz IP-k. Ez legegy- 
szerűbben a crontab-bal oldható meg. Egy tetszőleges 
nevű fájlba kell a crontab utasítást írni, majd rootként 
bejelentkezve crontab fájlnév paranccsal hozzáadni 
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a root nevében végrehajtandó crontab listához. Nálam 

a program 15 percenként fut, így a crontab utasítás a kö- 
vetkezőképpen néz ki: 

5-50/15 " " " " /eleresi ut/ipdisable 5/dev/nutl! 
2581 


A 5/dev/nut1 2584 részre azért van szükség, hogy a prog- 
ram futásáról ne küldjön e-mailt. 

A program minden egyes futásakor ír a naplóba, 

ezért legegyszerűbben a naplófájl (/var/log/ipdisable/ 
naplo.log) tartalmának megjelenítésével lehet ellenőrizni 
a működését: 


Start: Tue Feb 15 16:02:01 CET 2005 
Tiltva: 159.53.206.179 smtpext15.bankone. com 


Engedelyezve: 162.33.130.251 unknown 


End: Tue Feb 15 16:02:19 CET 2005 


Ha nem történt sem tiltás sem engedélyezés, akkor csak 

a programfutás indulásának és befejezésének időpontja lát- 
szik. A naplót érdemes rendszeresen átnézni, és megvizs- 
gálni, hogy nem tiltott-e ki olyan IP-t, ahonnan fontos levél 
is jöhet. 

A tiltottIPlog fájlba az éppen kitiltott IP-k találhatók 
IP:időbélyeg: tartomány formában: 


193.229.0.43:307876:fep34-O.kolumbus.fi 
204.140.14.154:307876:kitty.warnerbros . com 
64.243.89.147: 307876 : unknown 


206.168.3.177:307876 : unknown 


Az iptables paranccsal is lehet ellenőrizni, hogy milyen IP 
címek vannak kitiltva: 
iptables -L INPUT -n I] grep REJECT 


A következő parancs az éppen kitiltott IP-k számát írja ki: 
iptables -L INPUT -n I] grep REJECT I] wc -1 


Tapasztalat 

A program több hete működik. Az általunk használt gé- 
pen körülbelül 30 másodperc alatt lefut. Beüzemelése óta 
kollégáim nem panaszkodtak, hogy nem tudnak levelet 
küldeni, kézbesítetlen e-mail pedig csak az első napokban 
volt, amíg a nemti lthatoIpP fájlban meg nem adtuk az 
összes szükséges helyet. 


Jászberényi József 
kh! (jaszberenyijOpattantyus-gyor.sulinet.hu) 
Szeret biciklizni, kirándulni, olvasni, sörözni és 


1 szabadban főzni. A stratégiai játékoktól a mű- 
§ szaki CAD programokig sok minden érdekli. 
Legtöbbet szerverprogramokkal foglalkozik 


és néha mérgelődik. 
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Lokalizáció, házirendek, nyomtatók. 

lőző cikkem végére eljutottunk odáig, hogy egy 
e működő Windows tartományt létrehoztunk, ehhez 

a már megismert módon felhasználókat társíthat- 
tunk, bejelentkezhettünk. A felhasználókhoz tartozó profi- 
lok a szerveren kerültek tárolásra — ezt nevezzük barangoló 
profilnak (roaming profile) -, így a hálózatunk bármelyik 
gépén bejelentkezve ugyanazt a felhasználói környezetet 
használhatjuk. 
Ebben a cikkben teszek némi kiegészítést az előzőekben el- 
mondottakhoz, beállítjuk a tartományi házirendet, létrehoz- 
zuk azt a futtatható állományt, amely minden bejelentke- 
zéskor lefut a felhasználóknál, valamint nyomtatókat telepí- 
tünk. És a beállítások megkönnyítéséhez minden lépéshez 
mutatok működő példakódot is, amivel egy helyesen beállí- 
tott rendszert kiegészítve pillanatok alatt fel tudjuk az új 
tudással ruházni a rendszert. Lássunk is neki... 


Lokalizáció, avagy a magyar nyelv szépségei 

Ékezetes betűk, a hosszú Ő, a hosszú Ű. Minden rendszer- 
gazda és talán nem túlzás, minden tapasztaltabb felhaszná- 
ló rémálma. Egy ékezetes karakter egy angol operációs 
rendszerben, egy nyugat-európai karakterkészlettel olyan 
gubancokat tud okozni, ahol a meg nem jelenített betű még 
a legkisebb problémák közé tartozik. Szélsőséges esetben az 
ilyen állományok olvashatatlanná, sőt extrém esetben akár 
törölhetetlenné is válnak. Egy rémálomba illő történetem 
van erről, amikor egy angol Windows NT4-es rendszeren 
tárolt, de magyar Windows 98-ak által létrehozott állomá- 
nyokat kellett egy új, magyar nyelvű Windows 2000 alapú 
rendszerbe mozgatni. Természetesen az Ő és Ű betűk miatt 
a fájlokat közvetlen a két kiszolgáló között nem sikerült át- 
másolni, csak egy két rendszeren keresztülfuttatott kerülő 
útján sikerült az állományok nagy részét átmenteni. 
Hasonló problémák sajnos a Samba kapcsán is könnyel fel- 
merülhetnek, főleg az olyan heterogén rendszerekben, ahol 
az operációs rendszerek több nyelven is beszélnek, vagy 
olyan eltérő verziójú rendszereket üzemeltetünk, mint egy 
Windows XP és egy Windows 98, vagy éppen egy Linux. 
Egyfelől kínosan oda kell figyelni arra, hogy a kliensek és 

a kiszolgálók azonos kódlapot használjanak, mert ezt figyel- 
men kívül hagyva komoly meglepetések érhetnek minket. 
Sajnos azt nem állítom, hogy ezeket az óvintézkedéseket 
megtéve nem fogunk ilyenbe belefutni, de legalább ennyit 
tegyünk meg és akkor kicsit nyugodtabban alhatunk. 
Melyik kódlapot válasszuk?" — merül fel a jogos kérdés. 
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1. ábra 


Az abszolút megoldásnak a Unicode látszik, de sajnos 
jónéhány régi program inkább CP852-t, vagy ISO-8859-2-t 
használ, így tapasztalatom szerint érdemesebb inkább 

a korszerű Windows és Linux rendszereket is alapértelme- 
zésként erre a kódlap családra visszaállítani. Persze az ideá- 
lis megoldás az az, hogy ne használjunk sem a felhasználók 
nevében, jelszavakban, sem pedig a fájlnevekben ékezet be- 
tűket, de sajnos ez utóbbi elérése a felhasználóknál tapasz- 
talatom szerint nem egy egyszerű dolog. 

A sok problémafelvetés és boncolgatás után nézzük, hogy 
mit is kéne tenni, hogy a Sambát rávegyük egy adott kódlap 
használatára. A [global] paraméter szekcióba vegyük fel 

a dos charset - 852, illetve a unix charset - i508859-2 
bejegyzéseket. Ezután a Samba a kapott karaktersorozatokat 
a közép-európai kódolás szerint fogja használni, amennyi- 
ben a kódolás a rendszeren telepített és értelmezhető. 


A root, a rendszergazda és az administrator 

Sokszor előfordulhat olyan helyzet, amikor egy adott fel- 
használó több néven jelenik meg egy rendszerben. Ennek 
talán legtöbbször előforduló esete, amikor a rendszerben az 
operációs rendszerek nyelve nem homogén, így tartalmaz 
például angol és magyar nyelvű operációs rendszereket is. 
A rendszergazda felhasználói megnevezése ezen rendsze- 
rekben lehet Administrator, lehet Rendszergazda, vagy 
egyéb más nyelvű elnevezés. Ahhoz, hogy ne kerüljünk 
bajba és a tartományunkban ezek a felhasználók ugyanazt 
a felhasználót jelentsék, ehhez egy felhasználónév össze- 






































rendelést kell készíteni. Ezt megte-  fdssszzmerszazotosasmzzn HEH tésekben, de használhatjuk akár 
hetjük, ha az smb.conf állomány- GST D.élé es tnt "I a CUPS webes interfészét is, amit 
ban felvesszük a username map — [es . 5 JE] az adott gép 631-es kapuján 
/etc/samba/usermap bejegyzést. Sz g e tudunk elérni, valahogy így: 
Ennek a változónak az értéke az az teas ép ss gar http://10.0.0.1:631 

állomány, amelyben a felhasználói 2 jeténnátátattni [iga eettéstok Lépjünk be a weblapra, és alapér- 
összerendelések szerepelnek. telmezésként a root felhasználóval 
Az elhelyezkedése gyakorlatilag aa igeret telepíthetjük is a nyomtatókat. 
tetszőleges, a lényeg, hogy az Enytbtelvek Amennyiben nem csak a helyi 
smb.conf-ban a helyes állományt ús ke gépről (localhost), illetve nem csak 
adjuk meg. Jelen esetben én az B metéltözteek a root felhasználóval szeretnénk el- 
letc/samba/usermap állományt héseetek érni a rendszert, akkor ezeket a be- 
használom, amelynek tartalma állításokat megváltoztathatjuk az 
nálam a következő: 2. ábra letc/cups/cupsd.conf állományban. 


root - administrator rendszergazda 


viktor - devel 


tem azt, hogy amikor a tartományba a root, az administrator, 
vagy a rendszergazda felhasználóval lépek be, az gyakorlati- 
lag ugyanazt a felhasználót jelenti, ugyanazt a profilt haszná- 
lom, ugyanaz a jelszavam, stb.. Ugyanígy a viktor és a devel 
felhasználók is azonos felhasználói fiókot jelentenek. 


Bejelentkezési (logon) szkriptek és 

a házirendek — Nyomtatók kezelése 

Mostanra meglehetősen sokat foglalkoztunk a fájlok, 
könyvtárak megosztásával, de alig esett szó a nyomtatókról, 
pedig egy irodai munkakörnyezetben ezek az eszközök, 
illetve ezen eszközök elérése legalább annyira fontos, 

mint az állományok elérése. 

Mielőtt elmélyednénk a Samba és a nyomtatókezelés 
kapcsolatának rejtelmeiben vizsgáljuk meg egy kicsit, 

hogy miként is lehet Linux alatt nyomtatni. 

Linux alatt szerencsére találunk jónéhány megoldást 

a nyomtatóink kezelésére, így választhatunk ízlésünknek 
megfelelően. Én is ezt tettem és a CUPS nyomtatórendszert 
választottam. A CUPS (azaz a Common Unix Printing 
System) egy olyan nyomtatórendszer, amely a Linux rend- 
szerekben széleskörű támogatást élvez, könnyen konfigu- 
rálható és meglehetősen széles hardverskálát fed le. Debian 
alatt a CUPS csomagból telepíthető — a csomagot szerintem 
mindenki egész könnyen meg fogja találni — és a különböző 
nyomtatókhoz tartozó meghajtóprogramokat is telepíthet- 
jük a kedvenc csomagkezelőnk segítségével. 

A meghajtóprogramok egy nagy csoportja megtalálható 

a hpijs csomagban, illetve a foomatic csomagokban. Ezeket 
mindenképpen érdemes feltelepíteni. Ha valakinek olyan 
nyomtatója lenne, amely még ezekkel a csomagokkal sem 
működik, akkor érdemes a www.linuxprinting.org oldalra 
ellátogatni és onnan beszerezni a szükséges ppd fájlt. Ez 

a ppd fájl tartalmazza a nyomtató egyfajta PostScript leírá- 
sát, így Linux alatt ez szükséges a nyomtató kezeléséhez. 
Vannak már gyártók, akik gondolván a Linux felhasználók- 
ra már a gyári telepítőlemezen mellékelik ezt a pár kilobáj- 
tos állományt is — dicsérjük meg őket. 

Ha eljutottunk oda, hogy feltelepítettük a CUIPS-ot és 

a meghajtóprogramokat is, akkor állítsuk be a nyomtatón- 
kat. Erre vannak natív kliensek a különböző Linux terjesz- 
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Most viszont lépjünk tovább 
és telepítsünk fel egy nyomtatót. Nyissuk meg a CUPS 
weboldalát és lépjünk a Manage printers linkre, majd 
nyomjuk meg az Add printer gombot. A bejövő oldalon 
adjunk egy nevet -— amely a régi programokkal való kompa- 
tibilitás érdekében ne legyen nyolc karakternél hosszabb, 
valamint ne tartalmazzon ékezetes és speciális karaktere- 
ket -, majd adjunk egy pontosabb leírást és egy elhelyezke- 
dést a nyomtatóhoz. 
A következő oldalon ki kell választanunk, hogy milyen mó- 
don szeretnénk a nyomtatóhoz csatlakozni. A HP hálózati 
nyomtatóinál elterjedt a JetDirect-en keresztüli csatlakozás, 
amelynek a CUPS-ban nagyon jó támogatása van, így ha 
ilyen nyomtatónk van, bátran használjuk ezt a megoldást. 
Amennyiben olyan nyomtatóhoz szeretnénk csatlakozni, 
amely egy másik lInix/Linux kiszolgálóhoz van csatolva és 
az támogatja az ipp, vagy http protokollon keresztüli nyom- 
tatást — mint például a CUPS is —, akkor válasszuk ezt a csat- 
lakozási módot. Ezzel megtehetjük azt, hogy egy másik 
Linux szerverre lokálisan, vagy hálózatban csatolt nyomtató 
erőforrásait használjuk anélkül, hogy a másik gépen különö- 
sebb beállításokat kéne tenni, vagy meg kéne a nyomtatót 
osztani. (Természetesen a CUDPS beállításai között engedé- 
lyezni kell az ipp és http protokollon keresztüli elérést, vala- 
mint az sem árt, ha a tűzfalak nem tiltják a kapcsolatot, de 
más beállításra ezek után tényleg nincs szükség.) 
A CUPS természetesen támogatja a lokális csatlakozást is, 
így választhatjuk a párhuzamos kapun való csatolást épp- 
úgy, mint az USB-n való kommunikációt. És ezzel még min- 
dig nem értünk a kapcsolódási lehetőségek tárházának 
a végére, ugyanis használhatunk akár Windows kiszolgá- 
lón, vagy másik Samba szerveren megosztott nyomtatós is, 
a Windows Printer illesztést használva. 
Következő lépésként meg kell adnunk a pontos elérési utat 
a nyomtatóhoz, mégpedig egy szabványos internetcím for- 
májában, tehát a protokoll megnevezése, kiszolgáló címe, 
ipp://my.server.net/printers/myprinter) . Természetesen a cím 
formátumának meg kell felelnie az előző lépésben kiválasz- 
tott eszköz típusának. 
hátra, mint kiválasztani a nyomtató pontos típusát. 
Itt viszont álljunk meg egy szóra. Mivel jelenleg Windows 
munkaállomásokhoz készítünk nyomtatókiszolgálót, 
ezért érdemes megfontolni, hogy az alábbi két konfigu- 
ráció közül melyiket választjuk. 
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Az első beállítás szerint kiválasztjuk a nyomtatónk pontos 
típusát és bekonfiguráljuk, majd az így megosztott nyomta- 
tóra nyomtatunk. Ekkor azonban elképzelhető, hogy 

a munkaállomástól kapott nyomtatási fájl és a nyomtató lo- 
kális beállításai összevesznek és ez egészen odáig vezethet, 
hogy a nyomtatásunk végeredménye egy értelmetlen ka- 
raktersorozat formájában jön ki a nyomtatóból. Ezt a meg- 
oldást — tehát a pontos nyomtatómeghajtó kiválasztását 

a CUPS-ban - akkor javasolják, ha az adott gépről indítjuk 
a CUPS rendszeren a nyomtatást, tehát például tökéletes 
megoldás egy Linux munkaállomás esetén. 

A másik lehetőség, hogy RAW nyomtatónak telepítjük 

a nyomtatónkat, így a nyomtatószerver gyakorlatilag egy 
nyomtatási sorként fog funkcionálni, tehát a kliensektől 

az ott telepített meghajtóprogrammal lefordított utasítások 
bekerülnek a sorba és onnan érkezési sorban távoznak 

a nyomtató felé. Ez utóbbi megoldást javasolnám a Samba 
nyomtatókiszolgáló alkalmazása esetén, mivel így tudjuk 

a munkaállomásokon a natív Windows meghajtókat hasz- 
nálni, így a nyomtató minden funkcióját ki tudjuk használ- 
ni. Sőt, mindjárt beállítjuk, hogy a felhasználóhoz a megfe- 
lelő nyomtatómeghajtó is feltelepüljön anélkül, hogy erre 
neki oda kéne figyelni. 


És mi legyen a Sambával? 

Végeztünk tehát a nyomtató telepítésével, most már csak 
meg kell osztani a Windows ügyfelekkel, ami természetesen 
a Sambán keresztül történik, méghozzá meglepően egysze- 
rű módon. Amennyiben a CUPS nyomtatórendszert hasz- 
náljuk, akkor ezt elég tudatni a Sambával és ettől a pillanat- 
tól kezdve a Samba automatikusan megosztja a nyomtató- 
kat. A beállításokat természetesen az /etc/samba/smb.conf- 
ban kell elvégezni, teendőnk annyit, hogy az alábbi két sort 
beszúrjuk a konfigurációs állományba: 


printcap name - cups 
printing - cups 


Ha ezt a két sort beszúrtuk az smb.conf-ba és abban szerepel 
az alapértelmezett nyomtatómegosztás is, akkor a nyomtató- 
ink meg kell, hogy jelenjenek az adott gép kiosztásai között. 
A nyomtatók megosztására nálam az alapértelmezett beállí- 
tások vannak az smb.conf-ban, ezek a következők: 


[printers] 
comment - AI] Printers 


path - /tmp 
create mask - 0700 
printable - Yes 


browseable - No 


Amit a fenti beállításokon esetleg érdemes lehet megváltoz- 
tatni, az annak a könyvtárnak a helye, ahol a nyomtatás 
alatt az ideiglenes állományok tárolásra kerülnek. Akinek 
nem felel meg a /tmp, az cserélje ki ízlése szerint. 


És mi legyen a meghajtóprogramokkal? 

Ha elkészültünk a kiosztással és csatlakozni is tudunk 

a nyomtatóhoz, akkor már csak egy dolgunk maradt, még- 
pedig a megfelelő meghajtóprogram telepítése a kliensre. 
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3. ábra 


Ezt a lépést egész biztosan nem tudjuk kihagyni, hacsak az 
adott kliensre hasonló nyomtató már korábban nem került 
telepítésre, akkor a Windows egész biztosan szólni fog, hogy 
kérné a nyomtató meghajtóját. Ezt a lépést szintén lehet 
automatizálni, méghozzá úgy, hogy a kiszolgálón egy speci- 
álisan erre fenntartott megosztásban kitesszük a nyomtatók- 
hoz tartozó meghajtóprogramokat is, így a nyomtató csato- 
lásakor azok automatikusan települnek a kliensre. Ehhez 
először létre kell hozni a kiosztást, utána pedig nyomtatón- 
ként hozzá kell adni a megfelelő meghajtóprogramot. 

A kiosztást az alábbi kódrészlet beszúrásával hozhatjuk 
létre az smb.conf-ban: 


[print$] 
comment - Printer Drivers 
path - /var/l1ib/samba/printers 
write list - root, administrator 


A megosztáshoz azt hiszem sok magyarázatot nem kell fűz- 
ni. A path változó megadja, hogy a kiszolgálón hol lesznek 
tárolva a meghajtóprogramok, a write list pedig megadja 
azokat a felhasználókat, akik írási joggal rendelkeznek 

a könyvtárra, tehát akik nyomtató meghajtókat tudnak 
hozzáadni a rendszerhez. 

Ezután már csak hozzá kell adogatni a programokat a ki- 
szolgálóhoz, amit úgy tehetünk meg, hogy egy tartományi 
rendszergazda jogokkal rendelkező felhasználóval belé- 
pünk a tartományi kliensek egyikén, hozzáadjuk a nyomta- 
tónkat a klienshez, majd megnyitjuk annak tulajdonságait 
és a megosztások kezelésére szolgáló fülön a további 
illesztőprogramok hozzáadása gombra kattintva elkezdjük 
rendszerenként hozzáadogatni a megfelelő illesztőprogra- 
mokat. Amelyeket hozzáadtuk a rendszerhez, azok innen- 
től kezdve automatikusan települnek a nyomtatóval együtt. 


Nyomtatók csatolása bejelentkezéskor 

Lehetőségünk van arra is, hogy a nyomtatók telepítését, 
megosztások becsatolását, sőt akár programok telepítését is 
elvégezzük a felhasználó beavatkozása nélkül egy adott kli- 
ensen a felhasználó bejelentkezésével egyidejűleg. Ehhez 
mindössze annyit kell tenni, hogy összeállítjuk a megfelelő 
bejelentkezési (logon) szkriptet és azt elhelyezzük a koráb- 
ban létrehozott setlogon megosztásunkban. 
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4. ábra 


Ahhoz, hogy nyomtatókat telepítsünk, az alábbi parancso- 
kat kell itt elhelyezni: 


rem Nyomtatok telepitese 

rem KMDI2011 nyomtato 

rund1132 printui.díl,PrintuIEntry /dn /n 
se unyserverNkMDI20117 /g 

rund1132 printui.díl,PrintulEntry /in /n 
e unyserverNkMDI20117 /g 

rund1132 printui.dIl,PrintulEntry /y /n 
se unyserverNkMDI20117 /g 


Ezzel a parancskészlettel eltávolítjuk a nyomtatót, amennyi- 
ben az már létezett a rendszerben — mivel nem akarunk egy 
nyomtatóból több azonos példányt tartani — és hozzáadjuk, 
illetve telepítjük a megfelelő illesztőprogramot. 


PDF nyomtatása Windows alatt 

Nézzünk most egy érdekes problémát, amelyre egy Linux 
kiszolgálóval egészen könnyen találhatunk megoldást. PDF 
állományba való nyomtatás Windows rendszerek alatt szin- 
tén támogatott, akárcsak Linux rendszereknél, azzal az ap- 
rócska különbséggel, hogy ezekért a megoldásokért általá- 
ban elég komoly összegeket kell fizetni. Ellenben felmerül 

a kérdés, miért fizessünk, ha megoldható ingyen is? Ráadá- 
sul úgy, hogy a teljes rendszert saját ízlésünknek megfelelő- 
en tudjuk kialakítani. 

Nézzünk egy megvalósítási lehetőséget röviden összefoglal- 
va. Amit tennünk kell az annyi, hogy készítünk egy nyom- 
tató megosztást, majd az adott megosztásra érkező nyomta- 
tási parancsokat átfolyatjuk egy megfelelő szkripten, amely 
lefutása után generál egy PDF állományt a kimeneten. 
Pofonegyszerű, ugye? 

Nézzük egy kicsit konkrétabban, mire is van szükségünk. 
Először is készítsünk el egy nyomtató megosztást, amely 
nem egy eszközt, hanem egy futtatható állományt fog meg- 
hívni a beérkezett nyomtatási paranccsal. Helyezzük el az 
alábbi sorokat az smb.conf állományban 


Ismbpdf1] 
comment - PDF Generator 
path - /tmp 


printable - Yes 
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print command - /usr/sbin/pdfprint J7és 26U 
—96G 76m 76I 76H 


A fenti sorok jól láthatóan annyiban különböznek a nyom- 
tatóink megosztásánál használt beállításoktól, hogy itt talál- 
ható egy print command paraméter. Itt kell megadni azt 

a futtatható állományt, amelyikkel a beérkező PS állomány- 
ból a PDF-et elő szeretnénk állítani. Ez tulajdonképpen egy 
tetszőleges általunk készített szkript is lehet, amely után 
akár egy adott könyvtárban elhelyezni, akár e-mailben 
továbbítja a nyomtatott állomány PDF verzióját. 

Álljon itt egy példa a pdfprint szkriptre: 


!/bin/bash 

fconvert to pdf 

$$1 - spool file $2 -— uid $3 - gid $4 - 

s machinename $5 - ip $6 - homedir 
FILENAME-pdf-$2-" date --26d96m96H96M96S " . pdf 
OUTPUTPATH-$6/pdfwriter 

echo converting $1 to $FILENAME for $2 of machine 
5$4... $655 $OUTPUTPATH/pdfcreate.1log 
/usr/bin/ps2Zpdf $1 $OUTPUTPATH/$FILENAME 55 

5 $OUTPUTPATH/pdfcreate.]og 255 

5 $OUTPUTPATH/pdfcreate.10g 

echo conversion finished, removing $1 35 

5 $OUTPUTPATH/pdfcreate.10g 

rm $1 

echo done, setting permissions and notifing user 
sss $OUTPUTPATH/pdfcreate.1og 

chown $2:$3 $6/$FILENAME 55 

5 $OUTPUTPATH/pdfcreate.1o0g 

chmod 700 $6/$FILENAME 5: 

5 $OUTPUTPATH/pdfcreate.10g 

echo your new PDF is called $FILENAME. 
5-M $4 -I $5 

echo AI] done. 35 $OUTPUTPATH/pdfcreate.1log 
echo 35 $OUTPUTPATH/pdfcreate.log 
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] smbclient 


Ezzel a kóddal a bemenetre érkező nyomtatási parancsot 

a feladó felhasználó home könyvtárában létrehozandó 
pdfwriter könyvtárban fogjuk elhelyezni és a felhasználó 
nevével, valamint a készítés időpontjával lesz elnevezve. 
Ami még nagyon fontos, hogy kliens oldalon olyan nyom- 
tató illesztőprogramot használjunk, amely hagyományos 
PS állományt állít elő, amely lehetőség szerint nem tartal- 
maz semmilyen egyéb gyártóspecifikus kiterjesztést. Ilye- 
nek a HP Laserjet PS és Apple Laserwrite nyomtatók, így 
ezek valamelyikét használva jó eséllyel működő PDF gene- 
rátort kapunk. 

Ezzel mostani cikkem végére is értem, remélem sikerült 
olyan érdekes megoldásokat bemutatni, amelyeknek a min- 
dennapokban is hasznát lehet venni. A sorozat következő 
részében folytatjuk kalandozásunkat a Samba világában. 


Illés Viktor (viktorXei.hu) 

23 éves, a BME műszaki informatikus szakának 
hallgatója, mellette weblapokkal, linuxos 

és windowsos rendszerekkel foglalkozik. 
Szabadidejét legszívesebben a szabadban tölti, 
teniszezik és kerékpározik. 
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FreeBSD - a szomszéd vár 66. rész) 


Kiszolgálók — ACL és kiterjesztett attribútum a fájlrendszerben. 


a könyvtárak és az állományok eléréséhez megfelelő 

jogokat követel meg, ezekkel a jogokkal képesek a fel- 
használók az állományokhoz hozzáférni. Ez a jogrendszer 
alapvetően három részre osztotta a felhasználók körét: tulaj- 
donos, csoporttag és mindenki más. A UNIX történelem első 
évtizedében elegendőnek bizonyult, azonban mostanság ezek 
a jogok néhol erősen szűkösek lettek. S ez súlyos hiányosság, 
ha kiszolgálóként üzemeltetünk egy ilyen rendszert. 


s reeBSD - a legtöbb UNIX rendszerhez hasonlóan — 


A UNIX jogosultságok rendszere 

A régi nagygépes rendszerben minden bit kihasználásra ke- 
rült, mivel az erőforrások szűkösnek bizonyultak, s ennek 
megfelelően kellett jogosultságokat osztogatni állományok- 
hoz és könyvtárakhoz. A leginkább erőforráskímélő megol- 
dás felé hajlottak a fejlesztők, így csak az olvasás, az írás, il- 
letve a futtatás jogait rendelték hozzá a fájlokhoz, valamint 
meghatároztak egy tulajdonost és egy csoportot is. A teljes 
jogrendszer tárolására elég volt néhány bájt adatterület, és 
ez nagyon jó kompromisszum volt a fejlesztők részéről. 
Azt is mondhatnánk erre a kialakításra, hogy több a semmi- 
nél, de mindenre nem elég, s idővel a felhasználható tárte- 
rület is hatalmasra duzzadt, így ez a jogrendszer egyre in- 
kább szűkös lett. Nézzük egy egyszerű példát, ahol van né- 
hány felhasználónk: tomy, noobi, joe és franko. Ők mind 
egy munkahelyen dolgoznak, s néhány munkát meg kell 
osztaniuk egymás között. Például tomy dolgozik egy áram- 
kör tervezésén, amelybe noobi is belesegít, viszont joe meg 
sem nézheti ezt a munkát, mert egy titkos fejlesztése a cég- 
nek, miközben franko felügyelheti a tervezést. Ugyanakkor 
franko egy új programot fejleszt, amelyet joe és noobi csak 
megnézhet, viszont tony ki van zárva a fejlesztők köréből. 














Név Munka1 Munka2 
tomy rwx --- 
noobi rwx r-- 
joe --- r-- 
franko r-- rwx 





A legjobb megoldás egy táblázatba foglalni a hozzáférések 
körét, amelyből hamar kiolvashatjuk, hogy ki és milyen jo- 
gosultságokkal képes hozzáférni a megadott állományok- 
hoz. Megpróbálhatjuk ezeket a jogokat hozzárendelni a két 
állományhoz (munka1 és munka2), de csoportok nélkül ez 
nem fog menni. Triviális az a tény, hogy a két munkaállo- 
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mány csak kettő tulajdonossal jöhet létre, és a többiek jogait 
már csak a csoportjogokkal befolyásolhatjuk. Az is hamar 
észrevehető, hogy van mindkét munka esetén legalább egy 
olyan felhasználó, akinek egyetlen jogot nem tudunk adni. 
A második munka esetén létre tudunk hozni csoportot, 
amelynek tagjai (noobi és joe) csak olvasás joggal rendel- 
keznek, és elő is állt ennek a megoldása: 

$ 1s -1 munka2 

1 franko munka2 csoport 0 Feb 22 13:35 
"5 munka2 


Az első munkaállomány azonban szinte megoldhatatlan fel- 
adatot jelent, mivel nem tudunk kettő tulajdonost meghatá- 
rozni, vagy kettő (egy rwx és egy r-- jogú) csoportot ren- 
delni az állományhoz. Tulajdonképpen ez a , kis" probléma 
az oka annak, hogy UNIX (vagy UNIX-szerű) rendszerek 
nem tudtak betörni a fájlszerverek piacára, s nem tudták 
máig megtörni a Novell NetWare vagy a Microsoft Windows 
Server vezető szerepét ezen a területen. 


Az ACL hekapcsolása 

A FreeBSD 5.x az UFSZ fájlrendszeren támogatja az ACL 
használatát (a FreeBSD 4.x esetén új rendszermagot kell for- 
dítanunk), így képesek leszünk megoldani a jogosultsággal 
kapcsolatos problémáinkat. A kompatibilitás okán megma- 
radtak a megszokott jogok is, amelyeket azonos módon tu- 
dunk kezelni. Az ACL azonban alapértelmezés szerint nem 
aktív, bekapcsolásához a /etc/fstab megfelelő sorában meg 
kell adnunk az acis tulajdonságot is: 
/dev/adosif /usr ufs rw,acls ta 
Természetesen bekapcsolhatjuk a tunefs programmal is, 
amelynél a -a kapcsoló enabled állásával tehetjük ezt meg: 
$ tunefs -a enabled /dev/asOs1lf 


Ha mindezen túl vagyunk, akkor (elvileg) véget is ért 
a FreeBSD specifikus rész, s minden figyelmünket az ACL 
listák működésének megértésére tudjuk fordítani. 


Hogy láthatjuk meg az ACL jogokat? 

Kezdésképpen látni szeretnénk az ACL listákkal, hiszen 
— ha már beállítottuk — használnunk is kellene ezt a lehe- 
lekérdezésére, de megvan a módja, hogy -— például C 
nyelven - saját programból kezelhessük ezeket a listákat. 
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1. ábra ACL szerkesztése Windows alatt 





Igazából bármelyik állományra vagy könyvtárra le tudjuk 
kérdezni a listát, egyszerűen kiadjuk a 
$ getfacl munka2 


parancsot, mire — ha minden jól megy — megkapjuk az állo- 
mányunk eddigi beállításait: 

ffi le:munka2 

ftowner:1001 

$group:1008 


user: : rwx 
group: : r-- 
other : : -—-- 


Ez tulajdonképpen azonos az 
$ 1s -1 munka2 


parancs által kiírt 
1 franko munka2 csoport 0 Feb 22 13:35 
5 munka2 


sorral, csak az ACL-listából nem tudjuk meg, hogy állo- 
mánnyal vagy könyvtárral van-e dolgunk, illetve csak 
numerikusan láthatjuk a tulajdonost és a csoportját. 

A többi sor már az ACL-lista része, amelyet (angol nyel- 
ven) szövegesen olvasható formában láthatunk, s ennek 
a formátuma eléggé kötött, mivel csak a tradicionális 
UNIX jogokat láthatjuk. Tetszőleges állomány esetén ta- 
lálkozni fogunk wser, group és other jogokkal, mint ahogy 
ezt meg is szokhattuk. A különbség annyi, hogy látunk 
kettőspontokat, amelyek elválasztják egymástól a kulcs- 
szavakat és a jogok jelzéseit. A két kettőspont közé azon- 
ban olyan információkat tudunk írni, mint egy felhaszná- 
lónév vagy egy csoport. Sőt, ezekből többet is felsorolha- 
tunk; kezdésképpen oldjuk meg a munka2 állomány jogait 
ACL használatával. 


Hogy adjunk meg ACL jogokat? 

A jogok kezelését a setfac1 parancs végzi, ennek pa- 
rancssorában meg kell adnunk azon jogot, amelyet hozzá 
szeretnénk fűzni az eddigi listához. Ehhez először is egy 
kis módosításra van szükség az állományunk általános 
jogai környékén: 
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$ chmod 600 munka2 

$ chown :franko munka2 

$ 1s -1 munka2 

1 franko franko 0 Feb 22 13:35 munka2 


Ezzel a munka2 állomány tulajdonosa és csoportja egyaránt 
franko lesz (a FreeBSD esetén minden felhasználónak alap- 
ból a saját nevével létrejön egy csoport is), illetve csak a tu- 
lajdonosnak van olvasás és írás joga. Ha újra lekérdezzük 

a ACL jogokat, sok változás nem fog történni a fent végre- 
hajtott változásokat leszámítva: 

$ getfact munka2 

$file:munka2 

fowner:1001 

í$group:1003 

user : : rw- 

group: :--- 

other: :--- 

A hozzáférést leíró táblázat szerint noobi és joe férhet hozzá 
az állományhoz olvasás joggal. Őket egyszerűen csak hozzá 
kell adni a listához, majd rögtön meg is nézzük, mi változott. 


$ setfacl -m user:noobi : r-- munka2 
$ setfacl -m user:joe:r-- munka2 

$ getfacl munka2 

tfile:munka2 

towner:1001 

ígroup:1003 

user: : rw- 

user: joe: r-- 

user :noobi : r-- 


group : : --- 
mask: : r-- 

other : : --- 

$ 1s -1 munka2 

-rw-r----- 3: 1 franko franko 0 Feb 22 20:35 munka2 


Az első különlegességet az 1s parancs kimenetében talál- 
juk, mégpedig egy -- jel képében, amely azt jelzi, hogy a lá- 
tott jogoknál sokkal több jogdefinícióra kell számítanunk, 
mint amennyit látunk. Ezek a jogok a setfac1] parancs -m 
kapcsolójával kerültek oda, amely a merge rövidítése, így 
annyival több a szimpla hozzáadásnál, hogy nem ismétli 
meg az azonos sorokat. A getfac! listájában találkozunk is 
ezekkel a sorokkal, pont úgy, ahogy beírtuk őket. Az egyet- 
len ismeretlen sor a mask: : r-- lesz, amely annyit tesz, 
hogy a meghatározza a legmagasabb adható jogokat - le- 
számítva természetesen a tulajdonos saját ACL bejegyzését 
és az egyéb kategória jogait. Ez a maszk arra jó, hogy auto- 
matikusan mutatja a legmagasabb jogokat az ACL jogok 
közül, illetve azonos azzal amit az 1s -1 kiír a csoportra 
vonatkozó jogoknál. Megadhatunk csoportokra is jogokat, 
viszont törekedjünk arra, hogy tisztán csak felhasználókat 
adjunk hozzá a listához, bár sok olyan helyzettel találkoz- 
hatunk, mikor csoportokat egyszerűbb kezelni. 
Kipróbálhatjuk, hogy működik-e a megoldásunk, egysze- 
rűen a megnevezett felhasználókkal kell próbálnunk olvas- 
ni, írni vagy futtatni a megadott állományt (csodálkoznék, 
ha nem működne helyesen). A munkal állomány jogait 

is gyorsan beállíthatjuk: 
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TE MEEKESKEMAZSA ETETETT § setfac1 -d -n user:tony:rux 
$ chown tomy:tomy munkal BE ssÁramkörterv 
"AMunkákjáramkörterv nem érhető j 
$ setfacl -m user: tomy:rwx munkal € 98 vev setfacl: acl calc mask() failed: 
$ setfacl -m user:noobi : rwx munkal A hozzáférés megtagadva. s Invalid argument 
$ setfacl -m user:franko:r-- munkal sax setfacl: failed to set ACL mask on 
$ getfacl munkal [eom a s Áramkörterv/ 





$file:munkal 


2. ábra Hozzáférés megtagadva... 


fowner:10636 
$group:1008 
user : : rw- 

user :franko: r-- 
user : noobi : rwx 
user : tomy : rwx 
group : : —-- 
mask : : rwx 
other : : -—-- 


Az ACL jogok másolása 

Az egész játszadozás a jogokkal nem ér semmit, ha ezt min- 
den egyes új állományra alkalmaznunk kell. Egyik megol- 
dásunk erre az ACL ,átmásolása" egy másik állományra: 

$ getfacl munkal I] setfac!l -M - munka2 


Ezzel a módszerrel a munkal állomány ACL listája hozzámá- 
solódik a munka2 állomány ACL listájához. Ha ez utóbbi 
üres" volt eredetileg, akkor a két állomány listája azonos. Ez 
látszólag félmegoldás, mivel az új állományokra egyesével 
meg kell oldani ezt a másolást. Megtehetjük, hogy egyik állo- 
mány jogait levesszük egy másik állomány listájáról, ekkor a 
$ getfacl munkal ] setfacl -X - munka2 


parancsot kell használnunk. 


Az ACL jogok örökítése 

Rövid és egyszerű munkákat leszámítva a valóságos projek- 
tek több állományt, esetleg egy egész könyvtárstruktúrát je- 
lentenek. Ezeket az állományokat érdemes tehát egy közös 
könyvtárba tenni, és a könyvtárakkal is eljátszani a jogok 
kiosztásakor. Maradjunk meg a cikk eleje táján vázolt táblá- 
zatnál, csak az eddig használt állományok helyett egy 
könyvtárstruktúrát építünk ki, amely egy Munkák főkönyv- 
tárból, benne egy Áramkörterv és egy Program alkönyvtár- 
ból. Érdemes a projekt könyvtárát arra a felhasználóra átál- 
lítani, aki a gazdája annak, így az Áramkörterv tulajdonosa 
tomy lesz, a Program könyvtáré pedig franko. 

A setfacl -d kapcsolója felel az alapértelmezett ACL jogok 
kezelésért, amely öröklődik a könyvtárstruktúrában. Ha ezt 
a kapcsolót is megadjuk, akkor a hozzáfűzött lista lesz az 
összes — e könyvtár alatt — létrehozott állomány alapértel- 
mezett ACL joga. Az alapértelmezett listát a getfac! -d 
kapcsolójával tudjuk lekérdezni: 

$ getfacl -d Áramkörterv 

$file:Áramkörterv 

ftowner:10636 

$group:1008 


A listánk láthatólag teljesen üres, ezért hozzá kell 
adnunk néhány jogot. Ha ezt a tevékenységet nem 

a UNIX jogokkal kezdjük, akkor az alábbi hibaüzenet- 
tel nézünk farkasszemet: 
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A megoldás egyszerűen annyi, hogy először és lehető- 
leg egyszerre hozzá kell rendelnünk azokat a jogokat, 
amelyek az állomány tulajdonosára és a csoportjára 
vonatkoznak: 

$ setfacl -d -m u: :rwx,g: :---, o: :—--- 

S Áramkörterv 


Ekkor már hozzá tudjuk rendelni egyenként a felhasználók 
jogait a könyvtárhoz (ne felejtsük el, hogy a franko felhasz- 
nálónak adjunk x jogot is, különben nem fog tudni belépni 
a könyvtárakba): 

$ setfacl -d -m user:tomy: rwx Áramkörterv/ 

setfacl -d -m user:noobi : rwx Áramkörterv/ 

setfacl -d -m user:franko:r-x Áramkörterv/ 
setfacl -m user:tomy:rwx Áramkörterv/ 

setfacl -m user:noobi : rwx Áramkörterv/ 


setfacl -m user:franko:r-x Áramkörterv/ 


A LA A ta ta 


Az elkészült struktúrában már csak néhány próbát kell 
elvégezni, hogy láthassuk működés közben: 
franko Munkák/áramkörterv $ touch állomány 
touch: állomány: Permission denied 

franko Munkák/áramkörterv $ mkdir könyvtár 
mkdir: könyvtár: Permission denied 

tomy Munkák/áramkörterv $ touch állomány 
noobi Munkák/áramkörterv $ touch állomány2 
tomy Munkák/áramkörterv $ mkdir könyvtár 
noobi Munkák/áramkörterv $ mkdir könyvtár2 
tomy Munkák/áramkörterv $ touch állomány2 
touch: állomány2: Permission denied 


Hoppá... minden a tervek szerint működne, viszont egy 
apróságról megfeledkeztünk. Új állomány vagy könyvtár 
létrehozásakor az operációs rendszer néhány bitjét 
maszkolja a jogoknak. Alapértelmezésben ez 0022, amely 
szerint a csoport és az egyéb felhasználók nem lesznek 
képesek írni a létrehozott állományokba, s ez az ACL listák 
nélkül tökéletesen megfelelő megoldás. Azonban ez hatás- 
sal van az ACL maszkra is, így az újonnan létrehozott állo- 
mányok mask sora is változni fog: 

$ getfacl állomány 

tfile:állomány 

tfowner:10636 

ífgroup:1008 

user : : rw- 


user:franko:r-x ff effective: r-- 
user :noobi : rwx $ effective: r-- 
user : tomy : rwx ff effective: r-- 
group : : --- 

mask: : r-- 

other : : --- 











A megoldás egyszerű: vagy ideiglenesen megváltoztatjuk 
az umask parancs segítségével ezt a változót, vagy beépítjük 
a /etc/login.conf állományba. 

Nézzük mgg a változást: 

tomy Munkák/áramkörterv $ umask 0002 

tomy Munkák/áramkörterv $ touch állomány3 

noobi Munkák/áramkörterv $ umask 0002 

noobi Munkák/áramkörterv $ touch állomány3 
franko Munkák/áramkörterv $ umask 0002 

franko Munkák/áramkörterv $ touch állomány3 
touch: állomány3: Permission denied 


Vissza vannak még a könyvtárak ellenőrzése, de ez már 
nem okoz gondot: 

tomy Munkák/áramkörterv $ mkdir könyvtár 

noobi Munkák/Ááramkörterv $ mkdir könyvtár2 
franko Munkák/áramkörterv $ mkdir könyvtár3 
mkdir: könyvtár3: Permission denied 


A könyvtárak létrehozására is működik az alapértelmezett 
listánk, próbáljuk ki a könyvtárváltást is: 

tomy Munkák/áramkörterv $ cd könyvtár2/ 

noobi Munkák/áramkörterv $ cd könyvtár 

franko Munkák/áramkörterv $ cd könyvtár 


Tehát mindenki megkapta a futtatás jogok a létrehozott 
könyvtárakra. A próbát oldjuk meg úgy, hogy tonmy és 

noobi felhasználó egymás könyvtárába lépjen bele, ezzel 
kiderítjük, hogy képesek-e új állományt létrehozni, hogy 

a másik felhasználó a könyvtár tulajdonosa: 

franko Munkák/áramkörterv/könyvtár $ touch állomány 
touch: állomány: Permission denied 

tomy Munkák/áramkörterv/könyvtár2 $ touch állomány 
noobi Munkák/áramkörterv/könyvtár $ touch állomány2 


S végezetül az illetéktelen felhasználók jogait is érdemes 
megtekinteni: 

auth.gabor Munkák $ cd Áramkörterv/ 

-bash: cd: Áramkörterv/: Permission denied 


Kapcsolat a Samba programmal 

Mindennek a sok szövegnek nincs értelme, ha nem tud- 
nánk ezek után fájlszerverként használni rendszerünket. 
A Samba program képes az ACL támogatást kihasználni, 
csak úgy kell fordítanunk (vagy olyan lefordított binárist 
telepítenünk), hogy ezt tudatosítjuk is benne. Ezen túl 
más dolgunk nincs is, mint kipróbálni a megosztáson az 
említett jogokat. 

Ha például egy Windows ügyfélen felcsatoljuk a megosztást 
(a példában w: meghajtóként), és lekérdezzük az Áramkör- 
terv könyvtár jogait, akkor egyszerűen ugyan azokat a jo- 
gokat kell látnunk, mint amit kínkeserves munkával begé- 
peltünk a parancssorba. Egy kicsit látványosabb és 
könnyebb is egy ilyen megosztáson át piszkálni a hozzáfé- 
rési jogokat, a parancssori mókát hagyjuk a programocs- 
kákra és az esetleges apróbb módosításokra. 

Az ACL működését ki is próbálhatjuk — szintén Windows 
ügyfél segítségével. A megosztást olyan felhasználó nevével 
csatoljuk fel meghajtóként, akinek nincs joga olvasni sem 
az Áramkörterv könyvtár tartalmát, majd próbáljunk belép- 
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ni a megnevezett könyvtárba. Elvileg , A hozzáférés megta- 
gadva" üzenetet kell látnunk a képernyőn, demonstrálva 
ezzel a jól működő rendszerünket. 


Kiterjesztett attribútumok 

Sokszor jönne jól, ha egy állományhoz megjegyzéseket tud- 
nánk fűzni, például olyan képet hordozó állományhoz, 
amely formátum nem támogatja a megjegyzésmezőt. A ki- 
terjesztett attribútumok pont erre a célra szolgálnak: hozzá 
tudunk fűzni kiegészítő adatokat az állományainkhoz. 

Az ACL kezeléséhez hasonlóan itt a getextattr, 

a setextattr, az lsextattr és az rmextattr parancsok 
szolgálnak e tulajdonság kezelésére. Egy állományhoz több 
attribútum is rendelhető, ugyanis meg kell neveznünk az 
információt, amit tárolni szeretnénk. Ezen túlmenően két 
névtér közül kell kiválasztanunk a megfelelőt: user vagy 
system. Például a lementett nyers képhez hozzáfűztem 

a felhasználói névterületen egy tartalom nevű változóba 

a kép magyarázó szövegét: 

$ setextattr user tartalom "Samba - Egy könyvtár 

5 jogainak beállítása" Samba0l.bmp 

$ setextattr user idopont "" date " Samba0l.bmp 


Meg tudjuk nézni, hogy milyen attribútumok vannak egy 
állományhoz rendelve: 

$ lsextattr user Samba01l.bmp 
Samba01 . bmp tartalom idopont 

Illetve le tudjuk kérdezni a megnevezett attribútumot is: 
$ getextattr user tartalom Samba0l.bmp 

Samba01 . bmp Samba ACL kezelése 


Ha már nem szükséges, akkor törölhetjük is: 
$ rmextattr user tartalom Samba01l.bmp 


Ezt az információs területet sok érdekes dologra fel- 
használhatjuk, bár a legtöbb formátum esetén maguk 

a programok oldják meg az ilyen információk kezelését 
az állományon belül. 


Auth Gábor (auth.gaborDenaplo.hu) 

Egy pécsi középiskolában informatikát és prog- 
ramozást oktat. Tíz éve botlott először a UNIX 
rendszerekbe, 7 év Linux használat után kapta 
el a FreeBSD lázat, amiből máig nem tudott 
kigyógyulni. 








A FreeBSD projekt honlapja 
5 http:/Avww.freebsd.org 


A magyar FreeBSD honlap 
2 http:/Avww.freebsd.hu 


A magyar BSD honlap 
2 http:/Avww.bsd.hu 


A kézikönyv magyar fordítása 
2 http:/Avww.enaplo.hu/FreeBSD/handbook/ 
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Az eFiltk bemutatása (1. rész) 


Egy nagyon jól használható grafikus eszközkészletet (widget-set) szeretnék 
bemutatni. A neve eFltk, ami egyben utal az elődjére is. 


lső nekifutásra talán egy kis történelmi háttérrel 
E kell kezdeni az ismerkedést és a grafikus felületek 

általános működésének tanulmányozásával. Általá- 
nosságban elmondható, hogy egy grafikus felület fő műkö- 
dése a megjelenítés után az események feldolgozásából áll. 
A mai grafikus felületek mind esemény-vezérelt módon 
működnek és ez igaz a Win32, a Mac OS, az Xwindow 
megjelenítésére egyaránt. A program fő tevékenysége 
az események figyelése és továbbítása a grafikus felület 
egyes elemei felé. 
Az eFltk sem működik másképpen, azonban hosszú fej- 
lődési időszak után tisztultak le a körvonalak és alakult 
ki az az eszközkészletet, amiről most szó lesz. A készlet 
elődjét Bill Spitzak kezdte el fejleszteni, aki korábban 
a NeXT grafikus felületének fejlesztésével foglalkozott 
1987-ben. A korai változatot , views"-nek nevezték el, 
de sajnos zárt forráskódja miatt ma nem sokat tudhatunk 
róla. A következő állomás a Forms eszközkészletet megis- 
merése és jó tulajdonságainak átvétele volt, majd kiegé- 
szítések váltak szükségessé az OpenGL és GLX kiegészíté- 
sek használatához. Ebben az időszakban született meg 
valójában az FItk első változata, ami alapját képezi jelen- 
legi témánknak. 
Magát az eFltk készletet jelenleg hárman fejlesztik egy 
nagyobb projekt részeként. A munka célja egy általánosan 
használható grafikus munkakörnyezet kialakítása, amely az 
eFltk-ra épül és ebből következően gyors működésű és kis 
helyigényű alkalmazások összessége. A készülő munkakör- 
nyezet tartalmaz, munkaasztal kezelést, ikonok megjelení- 
tése lehetséges, része egy ablakkezelő, egy beállító alkalma- 
zás, egy naptár, óra és egyéb segédprogramok. A környezet 
neve Eguinox Desktop Environment vagy rövidebben ede. 
A linkek között megtalálható az eredeti változat és a bőví- 
tett változat is, amely már tartalmaz a tálcára elhelyezhető 
ikonokat is. 
Ennyi bevezető után azonban tekintsük át az eFltk legfon- 
tosabb tulajdonságait. Elsősorban fontosnak tarom meg- 
említeni, hogy a készlet minden gond nélkül használható 
Win32, Unix, Linux és Mac OS X környezetben a megfele- 
lő (MSVC-t- 4- , GNU C, MinGW) fordítóprogramok képesek 
lefordítani készletet és a vele készült alkalmazásokat is. 
Tehát egy több-platformos grafikus eszközkészletről van 
szó, ami Ct 4 nyelven készült. Objektum-orientált műkö- 
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tinci zet hé 

include cefik/FT File. Dialog.ha 

char "dit; 

char "prog; 

make. windi 

FI.Double. Window mainwindow 

FLLBox preview 
Fi-Button bt. about 


FILButton bt. config 


make ( 

FLLWindow configyindow 
FILButton bt. capply 
FILButton bt. cancel 
FiLinput imgair 
FIL Button bt. díraddi 
FILinput imgprog 
FI Button bt. progadd 





(2 cormiguration options 


1mage dir: [Text input a] 
Program: Text input a] 


0 Cancei 


1. ábra Az eFluid felületkészítő 


déséből adódóan azt gondolhatnánk, hogy a sebessége 
nem túl látványos, én azonban az elkészült alkalmazáso- 
kat és a példákat még így is gyorsabbnak találtam 

a GNOME vagy a GIK-- alkalmazásoknál. Ezt talán annak 
köszönheti, hogy az eseménykezelő ciklusa egy egyszerű- 
sített sémát követ. Az eseményeket mindaddig adja to- 
vább a vezérlőknek, amíg azt valamelyik le nem kezeli 
vagy amíg van még vezérlő a grafikus elemek között. 
Nincs szükség annak meghatározására, mely eseményeket 
melyik vezérlők fogadhatják, hiszen mindegyik megkapja 
és vagy kezeli vagy visszautasítja. Sok-sok feltételvizsgá- 
latot megtakaríthatunk ilyen módon, főleg ha egy bonyo- 
lultabb alkalmazásról van szó. 

Az eFltk-ban továbbá használhatunk OpenGL és GLX se- 
gítségével történő megjelenítést, nagyon sokféle vezérlő 
áll rendelkezésünkre és a fejlesztést nagyban megkönnyíti 
a grafikus fejlesztőkörnyezet az efluid. Erről az alkalma- 
zásról láthatunk egy képet az 1. ábrán. Az alkalmazás 
nagyban felgyorsítja a fejlesztés menetét, hiszen gyorsan 
megtervezhetjük az alkalmazásunk grafikus felületét, 
majd a külső rutinok elkészítésével és használatával füg- 
getleníthetjük a grafikus megjelenítést a program többi 
részétől. Természetesen egyszerűbb alkalmazások eseté- 
ben erre nincsen szükség és ilyen programokat akár szö- 
vegszerkesztő használata nélkül is készíthetünk az efluid- 














] FLAátan tá Jat a kapcsolatok létrehozására is. Lehetőségünk van MySOL 
GUI] Styleg Cse] és ODBC adatbázisokhoz kapcsolódni, majd az egyes 
vezérlőelemek értékét a lekérdezések eredményéből 
Mervef bt load [7 public meghatározni. Nagyon egyszerűen bővíthetjük további 
adatbázis kapcsolatokkal a meglévő készletet és találha- 
tunk az adatbázis rekordjainak szerkesztésére alkalmas 
párbeszédablakot is. 
Egy jól használható eszközkészletből nem maradhat 
ki a hálózati kapcsolatok kezelésére szolgáló osztály 
sem, melyekből az eFIltk-ban többet is megtalálhatunk. 
Lehetőségünk van IMAP, FTP és általános hálózati 
kapcsolat kezelésére a meglévő osztályok segítségével. 





char tfilename - fl select file(dir, 2 
if (filename) í 
preview-d)image(Fl Image : : read(file 


; 





Könnyedén elkészíthetjük az alaposztályból a szá- 
munkra megfelelő hálózati protokoll kezelésére alkal- 
; mas leszármazottakat is. 


aj I 2] A mai grafikus felületekből nem maradhat ki a képek 
when 


Claátbaik 


p 
kezelése sem. Találhatunk beépített képeket, melyeket 

user Dátá I Release 8] például alkalmazhatunk gombok vagy menüelemek lát- 
r wel ványosabbá tételére de a készlet alkalmas PNG, BMP, 
GIF, JPEG és XPM képek betöltésére és megjelenítésére. 
A képek adatait közvetlenül is elérhetjük, ami lehetővé 

[/ Overlays OK ] Cancel ] teszi, hogy képfeldolgozó alkalmazásokat készítsünk. 
KELÉSkeete eeeeákemáe emezt see kszzzászz Amennyiben nincs szükségünk különleges képkezelő 
2. ábra Kódszerkesztő az eFluid-ban műveletekre, a képek kezelését végző rutinokat ki is 
hagyhatjuk a kód szerkesztéséből így kisebb programo- 
kat készíthetünk. A későbbiekben vizsgálandó, 4. ábrán 
látható program mindössze 77 kilobyte, amelyből a képek 
43 kilobyte-ot foglalnak el a programban. 
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Említésre méltó, hogy a fejlesztők gondoltak a konfigu- 
rációs állományok kezelésére is, találhatunk olyan osztá- 
lyokat, melyekkel a megszokott INI állományok szerkeze- 
téhez hasonló beállításokkal dolgozhatunk. Az osztály 
egyszerűsíti a beállítások tárolását és betöltését, nagyban 
megkönnyítve ezzel mindennapi programozási feladata- 
ink ellátását. 

Szintén az eFltk jól használhatóságát bizonyítja az is, 

hogy az előre elkészített osztályok között találunk naptárat, 
gyors képkezelésre alkalmas memóriában módosítható 
(offscreen) bitképeket, állomány választó párbeszédablakot, 
szövegszerkesztőt és a színek kiválasztására alkalmas 
párbeszédablakot is. 

Egyetlen hátránya az elemkészletnek az, hogy a doku- 
mentáció nem teljes. Az ismert, változatlan részek doku- 
mentumai megegyeznek az eredeti Fltk dokumentá- 
cióval, így ezeket nem találjuk meg a html formátumú 





fd 


].L LTE TETTETETT ! dokumentumok között, ami újdonság, arról pedig 





nagyon gyakran csak az osztályfüggvények és változók 


3. élre OPENGL alkalmazás esíebán nevét tudhatjuk meg. Ez bizonyos szinten érthető, hiszen 


nem mindenkinek egyértelmű és megszokott, hogy fej- 


ban. A program ugyanis lehetővé teszi, hogy az ese- lesztés közben dokumentálja is a készülő kódot. Ez idő- 
mények kezelésére szolgáló kódrészleteket is a tervező igényes feladat, ugyanakkor nagyban könnyíti az érthető- 
felületen írjuk be a megfelelő helyre. A 2. ábrán látha- séget és az áttekinthetőséget. Személyes tanácsom, hogy 
tó egy egyszerű alkalmazás éppen a kódrészlet készíté- fejlesztés során alkalmazzunk valamilyen önműködő do- 
se közben. kumentáció készítő programot, mint például a Doxygen. 
Néhány mondat erejéig tekintsük át, hogy milyen ki- A program fejlesztése közben így a kóddal együtt készül- 
egészítések találhatók az elődhöz képest az eFltk-ban. het a dokumentáció és egyetlen parancs végrehajtásával 
Mindamellett, hogy az általános vezérlőelemeket megta- elkészíthetjük a HIML, RTF, LaTeX formátumban elérhe- 
láljuk (gombok, listák, választógombok, görgetősávok, tő dokumentációt is. A Doxygen segítségével néhány sza- 
menü, felbukkanó meni és további vezérlőelemek), bály elsajátítása árán akár magyar nyelvű, képekkel és hi- 
fontos megemlítenem, hogy a készlet alkalmas adatbázis vatkozásokkal gazdagított dokumentációt is készíthetünk. 
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Dohbantó 





a -Configuration options 1-IEIEd 


Image dir [/dovkaesharerwalipapers a] 
Program [/setbaima a] 





4. ábra Egyszerű eFltk alkalmazás 


A program ugyanakkor alkalmas az osztályhierarchia 
megjelenítésére is, melynek segítségével könnyen ért- 
hetővé tehetjük a forráskódokat és az általunk készített 
új osztályokat is. 

Az ismerkedést folytassuk most a klasszikus , Hello 
World" programmal. A grafikus felület megtervezésé- 
hez használjuk az efluid programot, és készítsünk egy 
ablakot, melyben egy gomb felirata legyen , Hello World". 
A grafikus tervezőprogram képes előállítani a C-t 4 
nyelvű forráskódot is, amit az 1-es listán láthatunk. 

A programban találhatunk három függvényt, melyek 
közül a make window építi fel a grafikus felületet. Amint 
láthatjuk a felület felépítése nem bonyolult, azonban 
mégis azt javaslom, hogy a generált kódhoz csak akkor 
nyúljunk szövegszerkesztővel, amikor már egészen biz- 
tosak vagyunk abban, hogy a felület nem fog változni. 
Nagyobb alkalmazások esetében az események kezelé- 
sére szolgáló függvényeket célszerű külön forráskód 
állományban tárolni, és a tényleges eseménykezelőkből 
ezeket a külső programrészeket meghívni. Így elérhet- 
jük, hogy a felhasználói felület független legyen a mű- 
ködéshez szükséges kódrészletektől. Tekintsük át most 
az első listát. 


finclude "hello.h" 
FI. Window" window; 


static void cb Hello(FIl Button", void") ( 
window-:hideO; 


; 


FI. Window" make windowO ( 
FI. window" w; 
fFI.window" o - window 


z new FI Window(280, 80, "Hello eFltk"); 
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w - o; 
0-sshortcut(Oxff1b); 

íFI. Button" o 

- new FI Button(25, 15, 230, 45, 
0-s]label font(fl. fonts-1); 
0-slabel size(24); 
0-scallback((FI. callback")cb Hello); 
: 

0-sendO; 

y 


return  w; 


"Hello world"); 


int main Cint argc, char ""argv) ( 


make window() ; 
window-sshowO) ; 
return  FI::runO; 


; 


A listán jól látható, hogy a program fő függvénye mind- 
össze három sorból áll. Az első sorban elkészítjük az ablak 
grafikus felületét, majd megjeleníti az ablakot. Ez után 
kezdődik a program eseménykezelő ciklusa, ami addig fut, 
míg valamilyen ablak látható a képernyőn. Az ablak eltün- 
tetéséről a gomb eseménykezelő függvénye gondoskodik 
mégpedig oly módon, hogy a fő ablakot elrejti. Ennek hatá- 
sára a program befejezi futását. 

A program lefordítására létezik egy egyszerű módszer: 

a parancssorban adjuk ki az 


efltk-config -compile hello.cpp 


parancsot. Így statikusan összekapcsolhatjuk a programot 

a szükséges rutinokkal és bármilyen Linux környezetben 
működésre bírhatjuk. 

A következő részben folytatjuk az ismerkedést az elemkész- 
lettel, addig is mindenkinek kellemes munkát és tanulást 
kívánok. 





Fábián Zoltán (dzooliDfreemail.hu) 

26 éves, jelenleg oktatóként dolgozik, 
szabadidejében szívesen foglalkozik Blenderrel, 
programozással és elektronikai tervezéssel. 
Szereti a természetet, túrázást, úszást és 

a kellemes baráti társaságot. 














Az Ede (Eguinox Desktop Environment) 
bővített változata: 
5 http://dzooli.uw.hu/ede-1.0.2-dzooli.tar.bz2 


Az eredeti fltk: 
5 http:/Avwwifltk.org 


Az eFltk honlapja: 
2 http://ede.sourceforge.net 




















Az SIMTP AUTH beállítása 


IP cím ellenőrzés helyett hitelesítsük Postfix kiszolgálónk felhasználóit név 
és jelszó alapján — avagy ami nem állandó, az fix, hogy megváltozik. 


gyszer volt, hol nem volt, volt egyszer egy 
8 rendszergazda. A szemfüles olvasó bizonyára fel- 

fedezte azt, hogy az előző cikkem is ugyanezen 
felütésszerű mondattal kezdődött. Az egybeesés nem 
véletlen. Hősünk ebben a mesében sem lesz más, mint 
a mérnöki tudományok teljes fegyvertárát zsonglőrként 
alkalmazó rendszergazda, aki alig várja, hogy a felhaszná- 
lók igényeinek kielégítése után következhessen a megér- 
demelt pihenés. 
Eme jubileuminak mondható második epizód sem külön- 
bözik az elsőtől. A rendszergazda vígan tengeti életét, míg- 
nem a felhasználók világvége hangulatot idéző sikoltásai 
nyomán szembekerül a problémával. Első benyomásra 
a problémának hét feje van és lángok csapnak fel szörnyű- 
séges torkából, de közelebbről megvizsgálva kiderül, hogy 
csak egy pici gyíkról volt szó. A szükséges intézkedések 
nyomán hősünk végleges megoldást talál, és láthatjuk 
a könnyű nyáresti szellő borzolta hajkorona sziluettjét 
a lemenő nap utolsó sugaraiban. 
Ne szaladjunk azonban előre! Rendszergazdánk munka- 
helyén a levelező kiszolgálót helyi hálózaton keresztül 
érik el a munkaállomások. Természetesen ugyanennek 
a számítógépnek van egy lába az Internet felé is, vala- 
mint egy DNS-ben jegyzett MX rekordja. Ez egy igen 
kellemes kialakítás, hiszen a kötelező biztonság mellett 
egyszerűen beállítható és karbantartható. Ne felejtsük el, 
hogy ha lehet választani, hősünk mindig az egyszerűbb 
megoldás mellett dönt. 
A levélküldő kiszolgáló egy előfordított Debian csomagból 
telepített Postfix. Miután a cég összes munkaállomása a he- 
lyi hálózaton van, kézenfekvő beállításnak tűnt a levélto- 
vábbítás (smtp relay) engedélyezése a teljes belső hálózatra. 
Miután történetünk rendszergazdája felvette az alábbi sort 
a /etc/postfix/main.cf tő konfigurációs állományba, az e-mail 
küldés már működött is. Csupán némi finomhangolás ma- 
radt hátra, melyet itt most nem részleteznék. 
mynetworks - 127.0.0.0/8, 192.168.0.0/24 
Telt, múlt az idő, és a cég vezetősége egy új iroda létrehozá- 
sát tűzte ki célul. Nem tervezték azonban külön SMTP ki- 
szolgáló felállítását a létesítményben. Feltételezték, hogy 
egy közönséges ADSL kapcsolat előfizetésével a levelezés 
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kérdésére megadták a választ. Sebtiben kiadták a paran- 
csot hősünknek, nevezetesen , legyen e-mail". Bár a rend- 
szergazdák isteni származása megkérdőjelezhetetlen 

tény, és így bizonyításra nem szorul, sajnos ezúttal nem 
élhetek a szent könyvekből ismert pátoszos fordulattal, 
miszerint , és lőn". 

A gondot az jelentette, hogy az ADSL előfizetés dinami- 
kusan változó IP címre szólt. Mikor rendszergazdánk fel- 
vetette ezt a problémát a cég vezetőinek, arra kellett rá- 
döbbennie, hogy minden jó szándék mellett a pánikhan- 
gulatnál többet nem tud elérni náluk. Így számba vette 

a szóba jöhető ötleteket és elkezdte latolgatni a várható 
előnyöket és hátrányokat. Négy gondolatfoszlány suhant 
át az agyán. 

Az első, és egyben magától értetődő ötlet a fentebb emlí- 
tett nynetworks sor bővítése. Mivel a Postfix alapvetően 

IP cím alapján azonosít, elképzelhető, hogy ha egy kellően 
tág tartományban engedélyezett a levéltovábbítás, akkor 
ezzel hősünk átvágta a gordiuszi csomót. A kellően tág 
tartomány jelen esetben azt jelentené, hogy fel kell venni 
azt a teljes IP cím tartományt, amelyből a távoli iroda 
internet-szolgáltatója (ISP. Internet Service Provider) 

IP címet oszthat. 

Égbekiáltó gaztett lenne a fentebb vázolt kósza gondolat 
kivitelezése. Ezáltal az összes, ugyanahhoz a szolgáltató- 
hoz tartozó vadidegen előfizetőnek engedélyezve volna 
a levélküldés. Ez nem pusztán biztonsági rés, de könnyen 
meg is utáltathatja vele magát a meggondolatlan admi- 
nisztrátor. A levélszemetet ontó kiszolgálót nem igazán 
szeretik az Internet harcedzett használói. Mi több, egy 
ilyen merénylet elkövetése után a kiszolgáló teljesen jo- 
gosan bekerülhet a Nyitott Átjárók Adatbázisába (Open 
Relay Database, http://www.ordb.org/) , ami által számos 
e-mail kiszolgáló eleve el fogja utasítani az összes, tőle 
érkező levelet. 

Második lehetőségként felmerülhet a dinamikusan osztott 
IP kézzel történő felvétele a fenti sorba. Persze ami kézi 
szerkesztéssel kivitelezhető, az megoldható szkripttel is. 
Még azonban így is rá kell bírni a távoli iroda átjáróját arra, 
hogy valahogyan tudassa az új címet, ezután újra kell tölte- 
ni a Postfix konfigurációt. Ez az elképzelhető legkörülmé- 
nyesebb, és túl sok helyen támadható. Néha be kell látni, 
hogy az egyszerűbb lehet bonyolultabb is. 


2005. április 69 


0 Kiskapu Kft. Minden jog fenntartva 





0 Kiskapu Kft. Minden jog fenntartva 





Az első két gyenge próbálkozásra fátylat borítva hősünknek 
eszébe ötlött, hogy látott már olyan levelező programot, 
ami támogatta a POP-before-SMTP nevű eljárást. Ez a kö- 
rültáncolt problémára egy olyan csellel nyújt megoldást, 
hogy a levelező program küldés előtt feljelentkezik a POP3 
kiszolgálóra. Miután ott hitelesítette magát, és az SMTP 
kiszolgáló erről tudomást szerzett, a felhasználó szabadon 
küldheti leveleit. Ezt azonban nem minden levelező ügyfél 
támogatja. 

A múlt megnyugtató homályába veszett gondolatkísérle- 
tek után rendszergazdánk rátalált a legelfogadhatóbb 
megoldásra. Az eljárás neve SMTP AUTH, és arról szól, 
hogy minden ügyfél az IP cím helyett egy név és jelszó 
páros segítségével nyer hitelesítést. A levelező progra- 
mokban csak egy ezt az információt kell megadni, a ki- 
szolgáló helyes beállítása mellett innentől zavartalanul 
folyhat az e-mail küldés. 

Ennek a módszernek megvan az a határtalan szépsége, 
hogy hosszú távú megoldást biztosít. Egy újabb telephely 
létrehozása után minden további beállítás nélkül használha- 
tó a levelező kiszolgáló. Mindössze a megfelelő felhasználó- 
kat kell létrehozni. Természetesen ezeknek nem kell rend- 
szerfelhasználóknak lenniük, de ez egy másik mese. Rend- 
szergazdánk megtalálta tehát a megoldást. Ezek után lás- 
suk, mi hogyan kivitelezhetjük az ötletet. 

A SASL a Simple Authentication and Security Layer rövidí- 
tése, és a 2222-es számú REC taglalja részletesen. Érdemes 
a Cyrus-SASL nevű megvalósítás használatában elmélyed- 
ni, ha másért nem, azért, mert temérdek dokumentáció áll 
rendelkezésre az Interneten a szoftver használatához. Szá- 
mos hitelesítési forrást kezel, sajnos azonban SOL adatbá- 
zisból, vagy LDAP kiszolgálótól egyelőre nem tudja közvet- 
lenül lekérdezni a szükséges információkat. Ilyen jellegű 
igény esetén a forráskód foltozása az egyetlen út. 

Telepíteni kell tehát egy Cyrus-SASL nevű szoftvert, vala- 
mint biztosítani kell, hogy a Postfix képes legyen a haszná- 
latára. Debian alatt ez egyszerűen a postfix-tls csomag kivá- 
lasztásával elérhető. Mivel ez a csomag függ a megfelelő 
SASL csomagoktól, és fel is ajánl számos olyat, ami hasznos 
lehet a későbbiekben, érdemes az összes szintű függőséget 
kielégíteni. Miután szélsebesen feltelepítettünk mindent, 
következhet a beállítás. 

Az első és legfontosabb teendő a meglévő main.cf állomány 
biztonsági másolatának elkészítése. Miután meggyőződ- 
tünk róla, hogy minden, amit ezután teszünk, visszafordít- 
ható folyamatot jelent, ragadjunk klaviatúrát és egy sokat 
próbált szövegszerkesztőnk segítségével nyissuk meg 

a konfigurációs állományt. Az első, amit a Postfix tudtára 
kell hozni, az az hogy használnia kell a SASL-t. 


smtpd sasl auth enable - yes 


Ezzel a sorral mellesleg remekül lehet ellenőrizni a postfix- 
tls csomag jelenlétét, illetve forráskódból történő telepítés 
esetén a megfelelő fordítás előtti beállítások helyességét. 
Ha a Postfix hibaüzenetet dob a fenti sorra hivatkozva, biz- 
tosak lehetünk benne, hogy hiányzik valamilyen összetevő 
a rendszerből. Következzen ezután egy biztonsági beállítás. 


smtpd sasl security options -— noanonymous 
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Ezáltal kizárható a névtelen bejelentkezés lehetősége, mivel 
az SMTP kiszolgáló fel sem fogja ajánlani az ügyfélnek a hi- 
telesítés ezen módját. A hitelesítési mód a sima szöveges 
bejelentkezéstől kezdve a Kerberos-ig sokféle lehet, beleért- 
ve az imént kizárt módot is. Egy bizonyos hitelesítési forrás 
használatakor, melyre később még visszatérünk, szükséges 
a következő. 

smtpd. sasl] local domain - $myhostname 

Ez egyfajta tartománynevet állít be, de hangsúlyozom, 
hogy alább még szó esik erről. Fontos továbbá a régebbi 
levelező programok támogatása is. 


broken sasl auth clients - yes 


A Microsoft Outlook Express 4, illetve a Microsoft Exchange 
5.0 két olyan meglehetősen régi levelező, amellyel az SMTP 
AUTH kommunikáció a szigorú szabványok megtartása 
mellett nem működik. A fenti sor ezen a gondon segít, és 
egyes szabványok enyhébb figyelembevételével lehetővé 
teszi azoknak az ügyfeleknek is a hitelesítést, melyek már 
kifejezetten korosnak mondhatók. Végezetül határozzuk 
meg, hogy a SASL hitelesített felhasználók küldhetnek 

a kiszolgálón keresztül levelet. 


smtpd recipient restrictions - 
permit sas] authenticated, 
permit mynetworks, 
check relay domains 


Látható, hogy a kiszolgáló a mynetworks sorban szereplő IP 
címekről továbbra is fogadja a levelet, egy másik lehetőség 
a hitelesítés. A fenti változtatások eszközölése után újra be 
kell olvastatni a Postfix beállítási állományait. Ezt az alábbi 
paranccsal érhetjük el. 


ft /etc/init.d/postfix reload 


A hitelesítés már működik is! Csak a hitelesítés forrása 
nincs meghatározva, ez viszont már csak ujjgyakorlat. 

A szigorúan hitelesítéssel kapcsolatos beállítások 

a /etc/postfix/sasl/smtpd.conf nevű állományban találhatók. 
Könnyen elképzelhető, hogy sok rendszeren ez az állo- 
mány nem létezik, ekkor kézzel kell létrehozni. Az is lehet, 
hogy a /usr/lib/sasl könyvtárban kell keresni a nevezett 
fájlt. Ez a helyzet többek között akkor, ha forráskódból 
történik a telepítés. 

Az állomány legfontosabb paramétere a pwcheck method. 
Valójában nincs is olyan sok beállítási lehetőség, de 

erre nem is volna szükség. Ezzel az egy paraméterrel 

a hitelesítés forrása könnyűszerrel állítható. A követke- 
ző sorral meghatározzuk, hogy sasldb-t használunk 
erre a célra. 


pwcheck method: sasldb 
Ez egy igen tipikus felhasználás. Nincs szükség az azo- 


nosításhoz külön démonra, ugyanis egy Berkeley adat- 
bázisból nyeri a felhasználónevet, illetve a jelszót. 











Az adatbázis a /etc/sasldb néven található. Ebben a név 
és jelszó mellett még egy tartománynév (realm) is sze- 
repel. Ennek az az oka, hogy ha egy levelező kiszolgá- 
ló több tartományért is felel, fontos lehet megkülön- 
böztetni az egyik tartományban szereplő felhasználót 

a másik tartománybeli azonos nevű felhasználótól. 
Fontos, hogy a sasldb használatakor a hitelesítés csak 
akkor sikeres, ha a Postfix main.cf állományának 

smtpd sas] local domain paraméterében ugyanazt 

a tartomány szerepel, mint ami az adott felhasználónév- 
hez tartozik ebben az adatbázisban. 

Már csak egy dolog maradt hátra. Hozzunk létre egy 
felhasználót, aki jogosult használni az SMIP kiszolgálót, 
IP címétől függetlenül. sasldb használatakor ez a követke- 
ző paranccsal tehető meg. 


$ saslpasswd -c -u mail.vallalat.hu geza 


Ezzel létrehoztunk egy /etc/sasldb nevű állományt, ha az 
még nem létezett, és szerepel benne az új bejegyzés. A fel- 
használó neve geza, a mail .vallalat.hu tartomány tagja 
(realm), jelszava pedig a saslpasswd által bekért szó. 

A sasldb egy Berkeley adatbázis, ezért ne számítsunk arra, 
hogy közönséges szövegmegjelenítővel emészthető formá- 
ban látjuk a tartalmát, viszont a sasldblistusers segítsé- 
gével remekül lehet böngészni is. 


$ sasldblistusers 


Felhívnám a figyelmet arra, hogy ha a Postfix gyökér- 
könyvtárat vált indulás után (chroot), ennyivel még nem 
fogja megtalálni /etc/sasldb néven az adatbázist. Ez a hely- 
zet az előfordított Debian csomag esetén is. Ez esetben az 
állományt másoljuk át a Postfix új gyökerébe. 


tf cp /etc/sasldb /var/spool/postfix/etc/ 
5 sasldb 


Elkészültünk. Természetesen a hitelesítési forrás megváltoz- 
tatásával elérhető, hogy ne legyen szükség külön felhaszná- 
lói névre és jelszóra az SMTP-hez. Például Cyrus IMAP ki- 
szolgáló esetén hitelesítési forrásként a pwcheck-et megadva 
az IMAP-es név és jelszó páros is minden további nélkül 
használható. További lehetőség a shadow érték, amivel 

a rendszeradatbázist foghatjuk munkára. Ez azonban 
komolyan ellenjavallt, amellett, hogy gyökérváltás után 

el sem érhető. 


Sok sikert a beállításokhoz és biztonságos levelezést 
mindenkinek! 





a Fülöp Balázs ladminoOguardware.com) 

21 éves, imádja a Túró Rudit, a Debian Linuxot 
és a teheneket. Kedvenc írója Slawomir Mrozek. 
Leginkább a számítógépes hálózatok biztonsága 
érdekli. A BME VIK műszaki informatikus 

szak hallgatója. 

















Látogasson el hozzánk! 


Virtuális könyvesboltunk egyedülálló választékot kínál 
magyar és angol nyelvű számítástechnikai könyvekből. 
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MuSOGÓ 


NySOL 5 - rég várt fejlesztések 


Megnézzük, hogy állnak a ,legnépszerűbb nyílt forrású adatbázis-kezelő" 


programmal a fejlesztők. 

assan 10 éve, hogy a MYySOL töretlen pályája elkez- 
L dődött. A siker talán annak volt köszönhető (és ez 
így van a mai napig), hogy a pehelysúlyú kategóriát 
célozták meg a fejlesztők. Ennek a döntésnek a legfőbb 
előnye, hogy a MySOL egyszerű és gyors, könnyen megta- 
nulható a használata, ideális a mindennapos igények kielé- 
gítésére. Hátrányként jelentkezik azonban, hogy a szolgál- 
tatások köre szűkebb, mint a vetélytársaké. Ez ellen úgy 
próbáltak védekezni, hogy szép fokozatosan bővítették a le- 
hetőséget, közben ügyelve rá, hogy ha nincs rájuk szükség, 
akkor épp olyan egyszerűen lehessen használni az adatbá- 
zis-kezelőt, mint annak előtte. 
Az adatbázis-kezelés témakörében már jó ideje jelen lévő 
tárolt eljárások megjelenésével a MYSOL készítői régi adós- 
ságukat törlesztették. Cikkünkben ezt, és egyéb, a témához 
kapcsolódó fejlesztéseket vizsgálunk meg közelebbről. 


Helyzetkép 

A cikk írásának pillanatában az 5.0.2-alpha fejlesztői válto- 
zat érhető el , legfrissebb kiadás" címén a MySOL honlap- 
ján. Az egyes lehetőségek megvalósítása és beépítése 

a programba folyamatosan történik, minden kiadás tartal- 
maz egy-két újítást, s mellette rengeteg hibajavítást. A vég- 
leges változat tehát nem csak annyival fog többet tudni, 
hogy alaposan le lesz tesztelve, de jónéhány, jelenleg nem 
szereplő szolgáltatással is bővülni fog. Nekünk azonban je- 
lenleg meg kell elégednünk a fenti változatszámú fejlesztői 
kiadással, de aggodalomra semmi ok, hisz ez is megfelelően 
körvonalazza számunkra, hogy egy esetleges következő al- 
kalmazásunknál milyen lehetőségeket vehetünk igénybe, 
ha a MYSOL adatbázis-kezelőt választjuk. 


Nézzük az elsőt: nézetek 

Az 5-ös változatban már lehetőségünk nyílik nézetek (view) ké- 
szítésére. Egy ilyen nézet nem más, mint egy SOL lekérdezés 
által reprezentált adathalmaz, amelyet úgy érhetünk el, mint- 
ha az egy önálló tábla volna. Jó hír, hogy a nézetek mindjárt 
irhatók is, tehát lehetőségünk van a rekordok módosítására 
(update), illetve új sor beszúrására (insert), bár ez utóbbi bo- 
nyolultabb nézetek esetén nehézségekbe ütközhet, de ilyenre 
egyébként is csak a legritkább esetben vetemedünk. 

A nézetek készítése viszonylag szabványosan történik, de 
van néhány megkötés. A nézet adathalmazát meghatározó 
lekérdezés nem tartalmazhat származtatott táblákat, nem 
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hivatkozhat felhasználói változókra, nem hivatkozhat átme- 
neti táblákra, és ami az egyik legfontosabb: nem hozhatunk 
létre triggereket (lásd később) a nézet soraira. 


Tárolt rutinok 

Egy tárolt eljárás olyan SOL nyelven írt parancsok összessé- 
ge, amelyet az adatbázis-kiszolgálón rögzítünk, s utána 

a programozásban használatos módon meghívhatjuk. Ek- 
kor elvégzi azokat az SOL utasításokat, amelyeket az eljárás 
törzsében meghatároztunk. Néhány bővítménynek köszön- 
hetően tehát gyakorlatilag programozhatunk az adatbázis- 
kezelő berkein belül. 

A megoldás egyik nagy előnye, hogy az adatbázissal kap- 
csolatos logika valóban az adatbázis szintjére kerülhet, nem 
teszi nehezen érthetővé a programkódot. A másik, talán en- 
nél is fontosabb előny, hogy az itt elvégzett műveletekben 
szereplő rekordok nem hagyják el az adatbázis-kiszolgálót, 
hanem ott helyben történik meg a feldolgozásuk. Ennek 
következtében nem csak a hálózati terhelés csökken, de 











mivel nincs késleltetés, maga a művelet is sokkal gyorsabb, 
mint a hagyományos esetben, arról már nem is beszélve, 
hogy az adatbázis-kiszolgáló ki tudja használni a saját maga 
által nyújtott gyorsítási lehetőségeket (például indexek). 

A MYSOL a tárolt eljárások kezelése során az SOL:2003 
szabványt követi, hasonlóan az IBM által fejlesztett DB2 
adatbázis-kezelőhöz. 

Ennek megfelelően van tárolt eljárásunk (stored procedure) 

és van tárolt függvényünk (stored function) , amelyeket a leírás 
közös néven tárolt rutinként (stored routine) emleget. A kettő 
között a lényegi különbség az, hogy a függvénynek van való- 
di visszatérési értéke. Na de nézzük ezt meg részletesebben. 


Az eljárások 

Olyan visszatérési érték nélküli eljárásokról van szó, ame- 
lyek tetszőleges számú paramétert fogadva azoknak megfe- 
lelően végrehajtanak egy utasításhalmazt. Eddig nincs is 
benne semmi különös, a dolog ott kezd érdekessé válni, 
amikor megnézzük ezeket a paramétereket. Minden para- 
méter alapvetően háromféle lehet: IN, OUT, és INOUT (KI, BE 
és KI-BE) típusú, amelyek azt határozzák meg, hogy az 
adott paraméter bemeneti paraméter-e, vagy kimeneti, eset- 
leg kétéltű. A bemeneti paraméterek a programozásban 
megszokott paraméterek, ezeket használjuk a függvényen 
belül, a kimeneti típusú paraméterek pedig visszatérési ér- 
téket képeznek. Egy ilyen kimeneti típusú paraméter csakis 
felhasználói változó (user variable) lehet, míg a bemeneti 
paraméter lehet konstans érték is (pl. egy szám). 

A jelleg és a paraméter név megadása után következhet 

a típus megadása, ami jelen pillanatban a MySOL által 
használt típusok (oszlop típusok) lehetnek. 

A tárolt eljárások a CREATE PROCEDURE parancs segítségé- 
vel deklarálhatók, és ha egynél több utasítást tartalmaz, 
akkor BEGIN és END kulcsszavak közé kell ágyazni az eljá- 
rás törzsét. Elkészülte után a call] ctárolt eljárás 

neve (paraméterek): módon hívhatók. 

További hasznos érdekesség az eljárásoknál, hogy használ- 
hatjuk benne a jól megszokott SELECT-es lekérdezéseket, 
amelyek a hagyományos esetben visszaadódnak, mint az 
eljárás eredményei, tehát az eljárás futtatása ilyen esetben 
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egyenértékű egy lekérdezés futtatásával. Fontos azonban 
megjegyezni, hogy ha több SELECT is lefut egy tárolt eljárá- 
son belül, azok eredményei külön keresési eredményként 
adódnak vissza, tehát jó, ha a kliens tudja kezelni az össze- 
tett lekérdezési eredményeket. 

Lássunk egy egyszerű példát az eljárások alkalmazására: 


CREATE PROCEDURE negyzet(IN szam INT,OUT negyzete 
INT) 
BEGIN 
SELECT szam"szam into negyzete; 
END 


Az eljárást az alábbi módon hívhatjuk: 
mysgl: CALL negyzet(4 , Ca) ; 

Ouery OK, 0 rows affected (0.07 sec) 
mysgl: SELECT (a; 
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1 row in set (0.00 sec) 


A példában a SELECT INTO szerkezetet alkalmaztuk, amely 
azt tudja, hogy a SELECT által visszatért értéket elhelyezi az 
általunk megadott változóba. 


Függvények 

A függvények rendelkeznek valódi visszatérési értékkel, 

s segítségükkel olyan számítási műveleteket végezhetünk, 
amelyek nem kapcsolódnak az adatbázishoz, illetve az ott 
tárolt adatokhoz, ugyanis egy függvényen belül nem hasz- 
nálhatjuk a SELECT, INSERT, UPDATE és a hasonló művelete- 
ket, tehát itt csak a kapott paraméterekkel dolgozhatunk, 
amelyek itt mindig bejövő értékeket takarnak. 

Hasonlóan az eljárásokhoz a függvények a CREATE 
FUNCTION parancs segítségével deklarálhatók, és ha egynél 
több utasítást tartalmaz, akkor BEGIN és END kulcsszavak kö- 
zé kell ágyazni az függvény törzsét. 

Minden függvénynek van visszatérési-érték típusa, amelyet 
a deklaráció során adunk meg. Hasonlóan az eljárásokhoz, 
mind a függvény paraméterei, mind a visszatérési érték tí- 
pusa MYySOL által használt típus kell legyen. 

Lássunk egy példát a függvények alkalmazására is: 


CREATE FUNCTION funcdemo(szam int) RETURNS INT 
BEGIN 

RETURN szam"szam; 

END 


A függvényt az alábbi módon hívhatjuk: 


mysgl: select funcdemo(4); 


h-t 4 
] funcdemo(4) I 
—--—-————————— 4 
I 16 I 
7--—-———————— 4 


1 row in set (0.00 sec) 
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Megjegyzés: Mind az eljárások, mind a függvények eseté- 
ben a törzs több BEGIN-END blokkból állhat, amelyek mind- 
egyike felcímkézhető. 


Vezérlési szerkezetek 

A tárolt rutinok önmagukban még nem jelentenének nagy 
áttörést, azonban az elérhető vezérlési szerkezeteknek kö- 
szönhetően valóban programozhatunk SOL nyelven. Van 
IF, van CASE, REPEAT és WHILE ciklus, nincs FOR ciklus, van 
viszont egy érdekes LOOP nevű szerkezet, amely azt tudja, 
hogy a hurok kezdete és vége közötti részt ismételgeti, egé- 
szen addig, amíg a hurkon belül a megfelelő LEAVE utasítás- 
sal a hurok elhagyására késztetjük a végrehajtást. Ezeken 
kívül létezik még egy ITERATE parancs, amivel a különböző 
ciklusokon belül kezdeményezhetjük a ciklus ismételt vég- 
rehajtását. (Az egyes szerkezetek szintaktikája megtekinthe- 
tő a MySOL honlapján.) 

Az itt felsorakoztatott lista teljes, és bár igen kevésnek 
tűnik, az a tapasztalatom, hogy a gyakorlatban elegendő, 

és az összes felmerülő probléma elvégezhető az elemek 
kombinálásával. 


Változók, elemek 
Csupán a vezérlési szerkezetekkel még nem sokra men- 
nénk, a programíráshoz változók is kellenek, és a felhaszná- 
lói változók nem feltétlenül alkalmasak erre a célra. 
A már emlegetett BEGIN-END blokkon belül azonban lehető- 
ségünk van különböző MySOL elemek és változók deklará- 
lására. Nézzük meg közelebbről ezeket az elemeket: 
Feltételek (CONDITION): Segítségükkel hibakódokhoz 
rendelhetünk neveket, amely nevekre aztán később 
hivatkozhatunk, amikor le akarjuk kezelni a feltételek 
által reprezentált hibát 
Hibakezelők (HANDLER): Ezeket az elemeket kivé- 
telkezelésre (exception) használhatjuk, ahol a kivételt 
a MYySOL kiszolgáló dobja egy hibakód formájában, 
mi pedig egy ilyen hibakezelő segítségével rögzíthetjük, 
hogy az adott hibakód felmerülése esetén milyen műve- 
letet kell végrehajtani. 
Változók (VARIABLES): Ezek a hagyományos értelem- 
ben vett lokális változók, amelyek MYySOL által használt 
típusúak lehetnek és rendelkezhetnek kezdőértékkel, 
de nem azonosak a felhasználói változókkal. 


Mindhárom elemtípust a DECLARE kulcsszóval kell bevezetni, 
a pontos szintaktika a MySOL leírásban található. 


Kurzorok 

A kurzor nem más, mint egy lekérdezés eredményének olyan 
átmeneti tárolási lehetősége, ahonnan később akár rekordon- 
ként is visszahozhatjuk az abban tárolt adatokat. MySOL-ben 
minden kurzorhoz tartozik egy lekérdezés, amelyet a dekla- 
ráció során kell megadni. A kurzort a későbbiekben egy válto- 
zó reprezentálja, amelyet megnyithatunk, értékeket olvasha- 
tunk ki belőle, majd lezárhatunk. Természetesen ezt is 

a DECLARE kulcsszóval vezethetjük be, és csak a tárolt rutin 
határait jelző BEGIN-END blokkon belül érvényes. 

Van egy olyan szabály, miszerint nem mindegy, hogy mi- 
lyen sorrendben deklaráljuk a fentebb emlegetett elemeket: 
hibakezelő után nem deklarálhatunk kurzort, és a változók 
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sorrendet kapjuk: változók, kurzorok, hibakezelők. 

Kicsit térjünk most vissza a tárolt eljárásokhoz, s lássuk, 
hogy a fentieknek mi köze az egészhez. A kurzorok nélkü- 
lözhetetlenek az eljárásokban lekérdezett eredményhalma- 
zok ciklikus bejárása érdekében, itt ugyanis nincs FOR 
SELECT (amely végigmegy egy lekérdezés eredményhalma- 
zán), mint más alkalmazások esetében. A dolgot úgy kell 
áthidalni, hogy készítünk egy kurzort, amely tartalmazza 

a lekérdezés eredményeit, majd ezen kurzor minden ele- 
mén végighaladva járhatjuk be az eredményeket. A ciklus 
akkor ér véget, amikor elérjük a kurzor végét. Ezt — jobb hí- 
ján — egy hibakezelő létrehozásával kell megoldani, amely 
bebillent egy jelzőbitet, amit a REPEAT-UNTIL ciklusban fi- 
gyelünk. Még mielőtt megijednénk, hogy ez milyen bonyo- 
lult (bár más SOL megoldásokhoz képest határozottan az), 
lássunk egy példát a fentire: 


create procedure curdemo() 
BEGIN 
DECLARE a int; 
DECLARE b char(255); 
DECLARE done INT DEFAULT 0; 
DECLARE cur1 CURSOR FOR SELECT id,nev from 
5 automarkak; 
DECLARE CONTINUE HANDLER FOR SOLSTATE "020007 SET 
done — 1; 
OPEN curl1l; 
REPEAT 
FETCH cur1 INTO a, b; 
IF NOT done THEN 
SELECT a as id, b as nev; 
END IF; 
UNTIL done END REPEAT; 
END 


Ez a példa semmi hasznosat nem csinál, csupán kiír néhány 
autómárkát és nevet, sajnos mindet külön lekérdezés ered- 
ményeképp. A fentebb leírt módszert viszont jól szemlélteti. 
A done nevű változó jelzi, ha elfogytak az eredményhalmaz- 
ból a rekordok, mivel a 02000-s SOLSTATE akkor következik 
be, ha az eredményhalmaz végére értünk. 


Kis összegzés 

Bár még nem értünk a cikk végére, hadd húzzak itt egy vona- 
lat, és írjam le, ami a tesztelés során felhalmozódott bennem. 
Több helyen is le van írva a MySOL dokumentációjában, 
hogy a rendszer még fejlesztés alatt áll, de azt hiszem, hogy 
ha nem lenne leírva, erre akkor is hamar rájönnénk. Igen 
szegényes az elérhető lehetőségek köre. A legfőbb nehézség 
az, hogy nem tudunk úgynevezett leválogatást készíteni, 
amely valamilyen szempontok szerint kiszűrné egy lekérde- 
zés eredményét, és csak a kritériumoknak megfelelő rekor- 
dokat adná vissza, ugyanis az eljárásnak nincs valódi vissza- 
térési értéke, a SELECT által visszaadott értékek viszont soron- 
ként különböző lekérdezési eredményként adják vissza a kí- 
vánt rekordokat. Nem lehet típust definiálni, amivel áthidal- 
hatnánk a visszatérési értékek problémáját, bár azzal itt nem 
is sokra mennénk, mivel a függvények nem nyúlhatnak az 











adatbázisban tárolt adatokhoz (de attól még hiányoznak az 
összetett változótípusok). Ezen túl körülményes, hogy csak 

a kurzorokon keresztül lehet hozzányúlni ciklikusan az ered- 
ményekhez, a kurzorok viszont rendkívül buták. Nem lehet 
bármilyen eredményt hozzáadni, nem lehet később hozzá- 
fűzni eredményeket, nem lehet benne pozicionálni, és még 
sorolhatnám. Szóval van még mit fejleszteni. 


Vissza a témához: Trigyerek 

A triggerek olyan speciális tárolt eljárások, amelyek valami- 
lyen esemény (INSERT, UPDATE, DELETE) esemény során hí- 
vódnak meg automatikusan. A trigger egy adott táblához 
van kötve, és az arra a táblára vonatkozó, előre megadott 
művelet során hajtódik végre. 

Általában adatbázisba írás előtti ellenőrzésre, írás utáni 
számított érték kiszámítására, törlés előtti adatok bizonyos 
részeinek rögzítésére, stb. használhatjuk. 

Megadható, hogy az adott esemény előtt (BEFORE), vagy 
után (AFTER) hajtódjon végre, egyébként egy szokványos tá- 
rolt eljárásról van szó, vagyis inkább függvényről... Eljárás, 
mert nincs visszatérési értéke, függvény, mert rengeteg 
olyan megkötés van, amit előzőleg a függvényeknél tapasz- 
talhattunk: nem lehet másik tárolt eljárást, vagy függvényt 
meghívni, nem lehet tranzakciót kezdeményezni, jóváhagy- 
ni vagy visszavonni, de ami a legfontosabb: nem hivatkoz- 
hatunk közvetlenül más táblákra, de még arra a táblára sem, 
amihez a triggert rendeltük. Egyedül az aktuálisan érintett 
rekord értékeit kaphatjuk meg, vagy írhatjuk felül az alábbi- 
ak szerint: INSERT esetén a beillesztendő rekord oszlopai el- 
érhetők a NEw. oszlopnév hivatkozással. Ebben az esetben az 
oszlopnév írható, azaz a SET NEW. oszlopnév-érték művelet 
lefut, ha megvan a megfelelő jogosultságunk. DELETE eseté- 
ben a törlendő rekord oszlopai érhetők el az OLD. oszlopnév 
szintakszissal, de csak olvasható módon. UPDATE művelet 
esetén a felülírandó rekord értékeit az OLD, az új rekord érté- 
keit pedig a NEw hivatkozáson keresztül lehet elérni (előbbi 
csak olvasható, az utóbbi írható). 

Ezen kívül van még egy olyan - egyébként természetes — 
megkötés, hogy egy eseményhez egy adott időben (tehát 
például BEFORE INSERT) csak egyetlen trigger tartozhat. 

Ha a fenti kivételeket leszámítjuk, akkor ugyanúgy használ- 
hatjuk, mint egy függvényt, élnek a vezérlési szerkezetek, 
vannak változóink, de nem láthatunk ki a függvényből. 
Nézzünk egy példát trigger használatára: 


CREATE TRIGGER ins szorzo BEFORE INSERT ON termekek 
-35 FOR EACH ROW SET NEW. fogyar z NEW. nagykerar 
sZ 


Ez a trigger beszúrás előtt kiszámítja a fogyasztói árat a nagy- 
kereskedelmi ár felszorzásával, majd maga az INSERT művelet 
csak ez után fut le, tehát az érték bekerül a táblába — anélkül, 
hogy a , felhasználói" oldalról bármit csináltunk volna. 

És még egy példa a MySOL dokumentációból, amely egy 
UPDATE eseményre levágja a megadott intervallumból kiló- 
gó értékeket. Íme: 


mysgls delimiter // 


mysgl3 CREATE TRIGGER upd check BEFORE UPDATE ON 
5 account 
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-5 FOR EACH ROW 


-3 BEGIN 

-s IF NEW.amount c 0 THEN 

-s SET NEW.amount - 0; 

sg ELSEIF NEW.amount 5 100 THEN 
-s SET NEW.amount - 100; 

-s END IF; 

-s5 END// 


mysgl: delimiter ; 


És ha már ide érkeztünk: hasznos újítás a delimiter pa- 
rancs, amely arra szolgál, hogy megadjuk vele, hogy az sal 
parancs bevitele során (parancssoros kliens estén) milyen 
karakter zárja le magát a parancsot. Mivel az alapértelme- 
zett határoló karakter a pontosvessző, ami egyben a tárolt 
rutinok nyelvének utasításait is lezárja, kénytelenek va- 
gyunk átdefiniálni ezt addig, amíg begépeljük (bemásoljuk) 
a rutint. Jelen esetben a // karaktereket használjuk határo- 
lónak, majd mikor végeztünk, visszaállítjuk az alapértelme- 
zett pontosvesszőre. 

Sajnos a jelenlegi rengeteg korlátozás miatt még néhány 
kevésbé bonyolult dologra sem tudjuk felhasználni, 

és a dolgozni sem egyszerű vele. 


Osszegzés 

Bár a fejlesztők törekvése helyes és tiszteletreméltó, még 
igencsak gyerekcipőben jár ez a dolog. A program készítői 
minden lehetséges ponton feltüntették, hogy a legtöbb le- 
hetőség jelenleg is bővítés alatt áll, és ezt tudomásul véve is 
azt kell mondjam, hogy komoly dolgokra jelenleg (és még 
pár hónapig ez így is marad) nem alkalmas. Hiába a pe- 
helysúlyú kategória zászlós hajója a MySOL, ezen projekt 
esetében ez nem számít, ugyanis a cikkben tárgyalt témakö- 
rök nem igazán sorolhatók ide, de ha figyelembe vesszük, 
hogy a tárolt rutinok kezelésénél soha nem fog a program 

a tökéletes sokoldalúságra törekedni, a tudása még akkor is 
gyenge. Hozzáteszem, az irány jól el van találva, csak még 
nem haladt az alkalmazás kellő számú lépést ezen az 
egyébként rögös úton. Nem beszélve az előbb már érintett 
problémáról, a pehelysúlyú megoldások alkalmazásáról egy 
inkább nehézsúlyú területen. Magam is kíváncsi vagyok, 
hogy a készítők hogyan fogják ezt a feladatot megoldani. 
Azt javaslom, várjunk még... érdemes próbálgatni, feltérké- 
pezni a jelenlegi fejlesztői változatot, és bár ezekre nem szok- 
tunk alkalmazásokat építeni, feltételezem, hogy az első stabil 
változtok sem fogják tartalmazni a teljes fegyverarzenált, így 
ha valaki MySOL-ben szeretne magasröptű adattárolási meg- 
oldásokat tárolt rutinokkal kezelni, az talán várjon egy kicsit, 
s előbb néhány közepes erősségű probléma megoldására tö- 
rekedjen. Majdnem biztos vagyok benne, hogy idővel ezen 

a területen is mélyen a szívünkbe lopja magát a MySOL. 


Komáromi Zoltán 


A MYSOL honlapja: 3 http :/Avww.mysal.com 


Magyar tükör: 5 http://mysal.sote.hu 
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Számítógép hálózatok (16. rész) 
Kapcsolatállapot alapú forgalomirányítás, 
hierarchikus forgalomirányítás 


Folytatjuk tovább a dinamikus forgalomirányító eljárásokkal, most egy gyakorlatban is 
széles körben használt algoritmust mutatunk be: a kapcsolatállapot alapú forgalom- 
irányítást. Ezek után megnézzük, mi a teendő akkor, ha hálózatunk olyan nagyra nőtt, 
hogy a forgalomirányító táblázatok már nem férnek el útválasztóink memóriájában. 


távolságvektor alapú forgalomirányítás ugyan már 
A egy dinamikus algoritmus volt, amit 1979-ig az 

internet elődje, az ARPANET is használt. A gya- 
korlatban azonban ez az eljárás megbukott. Leváltásában 
két dolog játszott szerepet. Először is az algoritmus dönté- 
seinek meghozatalakor nem vette figyelembe az egyes vo- 
nalak sávszélességét. Ez a kezdetek kezdetén nem jelentett 
gondot, mivel az összes vonal 56 kb/s-os áteresztőképesség- 
gel rendelkezett, de miután egyes vonalak sávszélességét az 
eredetinek a többszörösére növelték, ez a hiányosság súlyos 
problémává kerekedett. 
Az algoritmus bukásának valódi oka azonban nem ez 
volt, hiszen az eljárást könnyedén meg lehetett volna 
változtatni úgy, hogy figyelembe vegye az egyes vonalak 
közötti sávszélességbeli különbségeket is. Az igazi problé- 
ma inkább az volt, hogy az algoritmus a , rossz hírekre" 
továbbra is lassan reagált, és ezen még a megosztott 
látóhatár alkalmazása sem segített. Mivel a végtelenig 
számlálás problémájára nem sikerült elfogadható megol- 
dást találni, egy teljesen új forgalomirányítási eljárást 
kellett kifejleszteni. Itt kezdődik a kapcsolatállapot alapú 
forgalomirányítás története. 
Az algoritmus működése egyszerű: az útválasztók először 
a szomszédaikkal ismerkednek meg, majd megmérik a kö- 
zöttük lévő késleltetéseket. Az így kapott információkat az 
alhálózat többi útválasztójának is elküldik, majd Dijkstra 
algoritmusának segítségével kiszámítják az alhálózat összes 
pontjához a legrövidebb utat. 


Ismerkedés a szomszédokkal 

Az útválasztó első feladata tehát a szomszédság feltérképe- 
zése. Ebben segít neki egy speciális, úgynevezett HELLO 
csomag, amelyre minden útválasztó válaszol, és a válaszban 
elküldi saját egyedi azonosítóját. (Az azonosítók egyedisége 
nagyon fontos. Tegyük fel, hogy egy útválasztó azt látja, 
hogy két másik útválasztó is szomszédja az X című útvá- 
lasztónak. Ha az azonosítók nem egyértelműek, akkor nem 
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1. ábra Három router egy LAN-on 


lehet eldönteni, hogy a két útválasztó ugyanannak az útvá- 
lasztónak a szomszédja-e, vagy két különböző X azonosí- 
tójú útválasztó van az alhálózatban). 

Amikor egy útválasztót bekapcsolunk, akkor az , becsönget" 
minden szomszédjához, azaz kiküld egy HELLO csomagot 
az összes kimenetén, majd vár a válaszok megérkezésére. 
Felmerül a kérdés, mi történik akkor, amikor egy kimeneten 
keresztül több útválasztót is el lehet érni, például két vagy 
több útválasztó egy LAN-ra van felfűzve. Az 1. ábrán egy 
ilyen topológiát láthatunk, ahol A, C és F útválasztó közvet- 
lenül, egy LAN-on keresztül kapcsolódnak egymáshoz. 
Ilyen esetekben célszerű a LAN-t helyettesíteni egy ,virtuá- 
lis" csomóponttal. A 2. ábrán a LAN-t kicseréltük egy N cím- 
kéjű pontra. Ezek után például az A-ból a C-be az ANC 
úton keresztül juthatunk el. 


Késleltetések mérése 

A szomszédokat nem elég megismerni, hanem azt is tudni 
kell, hogy mekkora a -— szomszédokhoz vezető — vonalak 
késleltetése (vagy költsége). Erre a feladatra is egy speciális 
csomagot alkalmaznak, amelynek neve ECHO csomag. 
Amikor egy útválasztó egy ilyen csomagot kap, azt soron 
kívül, azonnal visszaküldi azon a porton, amelyiken beérke- 
zett. Miután az útválasztó kibocsátott egy ECHO csomagot, 


























2. ábra A LAN-t úgy is felfoghatjuk, mint az alhálózat 
egy csomópontját 
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3. ábra Az ehhez hasonló toplógiájú hálózatokban nem feltétlenül 
előnyös, ha a vonalak költségeinek kiszámolásakor a terhelést 
is figyelembe vesszük 


megméri, mennyi időbe telik, míg visszaér hozzá. Ha ezt az 
időt osztjuk kettővel, akkor egy becslést kaphatunk az útvá- 
lasztó és a szomszédja között lévő vonal késleltetésére. 

A pontosabb becslés érdekében ezt a mérést időnként érde- 
mes megismételni. Ilyenkor a becsült költség mindig a mé- 
rések eredményeinek az átlaga. 

Ha a vonal késleltetésének becslésekor figyelembe szeret- 
nénk venni a terhelést is, akkor a mérés menete annyiban 
különbözik az előbbiektől, hogy az útválasztó az ECHO 
csomagot a várakozási sor végére teszi (ahol az útválasztón 
átmenő csomagok is várakoznak), és a ,stoppert" onnantól 
indítja (nem pedig attól az időponttól, amikor az ECHO 
csomag távozik az egyik kimeneten). 

Látszólag értelmetlennek tűnik az a kérdés, hogy figyelem- 
be vegyük-e a terhelést, vagy sem. Mondhatnánk, hogy 
persze, vegyük figyelembe, hiszen ha van két ugyanolyan 
sávszélességű vonal, ahol az egyik teljesen leterhelt, a mási- 
kon pedig éppen semmi sem csordogál, akkor az utóbbi le- 
gyen része a kijelölt útnak. A logikus választás valóban ez 
lenne, hiszen így a csomag jóval hamarabb célba érhet. 
Vannak azonban helyzetek, amikor kifejezetten hátrányos, 
ha a késleltetésbe a terhelést is beszámítjuk. Vessünk egy 
pillantást a 3. ábrára! Láthatjuk, hogy az alhálózat nyugati 
részét a keleti résszel a CF és az EI vonal köti össze. Tegyük 
fel, hogy a legtöbb kelet felé menő csomagot a CF vonalon 
keresztül irányítjuk, így ott a terhelés sokkal nagyobb lesz, 
mint az EI-n. Ha a becsléskor a vonal terhelését is megvizs- 
gáljuk, akkor azt fogjuk kapni, hogy a csomagok EI-n ke- 
resztül kisebb késleltetéssel jutnak célba. Ezek után a kelet 
felé tartó forgalom oroszlánrésze az EI-n kerül továbbításra, 


www.linuxvilag.hu 


így az válik terhelté, míg a CF-en a forgalom ritkul. Ne cso- 
dálkozzunk, ha a következő becslés eredményeképpen 

a CF lesz része a legrövidebb utaknak. 

A vonalak késleltetésének folyamatos változása miatt az út- 
választók forgalomirányító táblázatai is állandóan módosul- 
nak, méghozzá túl gyorsan. Ez nem túlzottan szerencsés 
dolog, ugyanis a forgalomirányítás nem lesz megbízható, 
és rengeteg nem várt problémával is szembesülhetünk. 
Ilyen esetekben tehát nem jó, ha a terhelést is nézzük az 
egyes vonalakon. Ehelyett megtehetjük például azt, hogy 

a forgalmat testvériesen megosztjuk a két vonal között, 
habár így nem biztos, hogy minden csomag a lehető 
legrövidebb úton fog célba jutni. 


Kapcsolatállapot csomagok 

Eddig sok újdonságról nem volt szó, a fentiekkel már talál- 
kozhattunk valamilyen formában a távolságvektor alapú 
forgalomirányításnál is. A kapcsolatállapot alapú forgalom- 
irányítás lelke azonban az úgynevezett kapcsolatállapot 
csomagok, amelyek segítségével az útválasztó megoszthatja 
társaival az általa összegyűjtött adatokat. Ezek a csomagok 
tartalmazzák egyrészt a feladót, annak életkorát (lásd ké- 
sőbb), illetve annak szomszédait, és az azokhoz tartozó 
késleltetéseket. Ezeket az információkat az alhálózat összes 
útválasztója kicseréli egymással. A 4. ábrán láthatunk példát 
az alhálózaton terjedő kapcsolatállapot csomagokra. 

Nem egyszerű az a kérdés, hogy egy útválasztónak mikor 
érdemes összeállítani és szétküldenie a kapcsolatállapot 
csomagjait. Általában kétféle megközelítést alkalmaznak. 
Az első esetben az útválasztók periodikusan, azaz szabályos 
időközönként küldik szét az általuk összegyűjtött adatokat. 
A másik lehetőség az, hogy a kapcsolatállapot csomagok 
csak bizonyos események bekövetkeztében jönnek létre, 
például ha egy vonal megszakad, vagy egy szomszéd útvá- 
lasztó elhalálozik, illetve megjavul. 

A kapcsolatállapot csomagokat az útválasztók az elárasztás 
módszerével szórják szét az alhálózaton, tehát az átmenő 
kapcsolatállapot csomagokat az útválasztók az összes kime- 
netükön továbbküldik (kivéve azt a portot, amelyikről 

a csomag beérkezett). Mivel ez a módszer exponenciális 
léptékben gyártja a csomagok duplikátumait, a folyamatot 
valamiképp kordában kell tartani. Az előző részben bemu- 
tattunk erre egy megoldást, miszerint minden csomagnak 
kell rendelkeznie egy sorszámmal, amely minden csomag- 
küldés alkalmával eggyel nő. Minden útválasztó számon 
tatja, hogy melyik portról milyen sorszámú csomagok ér- 
keztek eddig. Ha egy olyan csomag jön, amelynek a sorszá- 
ma nincs ezen a listán, akkor azt az útválasztó elárasztja, és 
a sorszámát feljegyzi. A listán szereplő sorszámú csomagok 
viszont többé nem kerülnek elárasztásra. Az ilyen csomago- 
kat az útválasztók egyből ki is dobják. 

Ez ugyan egy jól használható módszer, mégis akadnak vele 
problémák. Az első és legkézenfekvőbb dolog az, hogy ha 

a sorszámok egyszer csak átcsordulnak, akkor az egész 
rendszer dugába dől. (Ha például egy bájttal ábrázolnánk 

a csomagok sorszámait, akkor a 255. sorszám után a 0 lenne 
a következő, amelyet egy útválasztó sem fog elárasztani). 
Erre igazából csak egy megoldás létezik, mégpedig az, hogy 
a sorszámokat minél több biten ábrázoljuk. Persze a problé- 
ma még így is fennáll, viszont például 32 bit esetén a sor- 
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4. ábra Kapcsolatállapot csomagok 


számok csak 137 év múlva fordulnának át. (Feltéve ha az 
útválasztók átlagosan másodpercenként indítanak kapcso- 
latállapot csomagokat). 

Persze az útválasztók nem arról híresek, hogy matuzsálemi 
korokat éljenek meg, előbb-utóbb mindegyik elromlik, ki- 
fagy vagy egyéb katasztrofális eseményekkel kell szembe- 
sülnie. Út€tválasztóink halandósága újabb problémákat szül: 
elfelejtik, hogy milyen sorszámú kapcsolatállapot csomago- 
kat bocsátott már ki. Ha a sorszámozást a nullánál kezdi, 
akkor valószínű, hogy csomagjai nem jutnak messzire, 
hiszen a többi útválasztó elavultnak fogja tekinteni őket. 
Az is problémát rejt, hogy az útválasztók lista helyett csak 
egy számlálót tartanak karban. A számláló aktuális értéke 
alatti sorszámok jelölik az elavult csomagokat. Ha egy na- 
gyobb sorszámú csomag érkezik, az útválasztó azt elárasztja, 
majd a számláló értékét a csomag sorszámára növeli. Ez egy 
rendkívül memóriatakarékos módszer, viszont a bithibákra 
nagyon érzékeny. Ha ugyanis a sorszámban csak egy bit is 
megsérül, akár nagyságrendekkel nagyobb számot is kap- 
hatunk. Például a 2-es és a 65538-as sorszám bináris alakja 
közötti eltérés csupán egy bit. Ha az útválasztó egy ilyen cso- 
magot kapna, akkor 2-től 65538-ig minden csomagot el fog 
dobni. A probléma megoldásához szükséges, hogy a csomag- 
ba a sorszám mellé egy életkor mezőt is definiáljunk, amely- 
nek értéke másodpercenként eggyel csökken. A csomagok 
életkorát az útválasztók is csökkentik elárasztáskor. Amikor 
egy csomag életkora eléri a nullát, akkor megsemmisül. 

A gyakorlatban a beérkező kapcsolatállapot csomagok nem 
kerülnek egyből továbbításra, hanem először egy pufferbe 
kerülnek. Ha ugyanattól a forrásból még egy kapcsolatálla- 
pot csomag érkezik, akkor az útválasztó összehasonlítja a két 
csomag sorszámát. Ha ezek megegyeznek, akkor a második 
csomag már egy duplikátum, így az eldobható. Ha a sorszám 
különbözik, akkor a régebben érkezett csomag által hordo- 
zott információ már nem érvényes, így azt kell kidobni. 
Hogy az algoritmus még robosztusabb legyen — azaz 
ellenállóbb legyen a nemvárt vonalhibákkal szemben — 

az útválasztók a megkapott kapcsolatállapot csomagokat 
nyugtázzák egymásközött. Hasonlóan a kapcsolatállapot 
csomagokhoz, a nyugták sem kerülnek azonnal elküldésre, 
először ők is a pufferben várakoznak. 
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5. ábra Kétszintű hierarchikus forgalomirányítás 


A pufferben a csomagok mellett a forrásuk, a sorszámuk, 

a koruk és a küldési, illetve a nyugtázási jelzőik is tárolva 
vannak. Ezek közül az utóbbi kettő szorul még némi 
magyarázatra. A küldési jelző azt mondja meg, hogy 

a kérdéses csomagot mely kimeneteken kell továbbítani, 

a nyugtázási jelző pedig azt határozza meg, hogy a nyug- 
tát kinek kell visszaküldeni. 

Mit nyerünk ezzel? Tegyük fel, hogy a 4. ábrán feltüntetett 
alhálózati topológiában a B útválasztó kétszer is az E útvá- 
lasztó kapcsolatállapot csomagot. Például először az EAB 
majd az EFB útvonalon keresztül. Ebben az esetben 

a csomagot felesleges minden porton elárasztani, elegendő 
csak a C felé vezető kimeneten. Így az útválasztó a puffer- 
ben átírja a csomag küldési jelzőjét úgy, hogy csak a C felé 
továbbítódjon (a nyugtát viszont A-nak és F-nek is vissza 
kell küldeni). 

Ezzel a technikával csökkenthetjük a kapcsolatállapot 
csomagok által előidézett forgalomnövekedést. 


Az új útvonal kiszámítása 

Miután az útválasztók kicserélték információikat, felépíthe- 
tik az új forgalomirányító táblázatot. A legrövidebb utak 
kiszámítása a Dijkstra algoritmus segítségével történik. 
Fontos megjegyeznünk, hogy a kapcsolatállapot csoma- 
gok révén megkapott információ mérete jóval meghaladja 
a forgalomirányító táblázat méretét. Gondoljuk csak meg: 
ha az alhálózatban N darab útválasztó van, és minden 
útválasztónak K darab szomszédja van, akkor a beérkező 
adatok tárolásához legalább K"N méretű memóriára van 
szükség. Ha nagyon nagy a hálózat, akkor ez komoly 
gond, mivel nem áll rendelkezésre elegendő memória 
(sőt, az igazán nagy hálózatok esetében a teljes forga- 
lomirányító táblázat sem fér el az útválasztó memóriá- 
jában). Nem is beszélve a hálózat méretével arányosan 
növekvő számításiigényről, amely az új táblázat kiszámí- 
tásához szükséges. 

Ennek ellenére a kapcsolatállapot alapú forgalomirányítást 
a mai számítógép hálózatokban is széles körben használják. 
A későbbiekben részletesen megismerkedünk olyan proto- 
kollokkal, amelyek erre a forgalomirányítási eljárásra épül- 
nie (például az OSPF protokoll). 
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6/a. ábra Az , A" útválasztó táblázata hierarchikus 
forgalomirányítás nélkül 


Hierarchikus forgalomirányítás 

Az imént említettük, hogy az alhálózat méretének növeke- 
dése maga után vonja a útválasztók forgalomirányító táblá- 
zatainak növekedését is. Előbb-utóbb alhálózatunk akkorá- 
ra duzzadhat, hogy nem lesz olyan útválasztó, amely ele- 
gendő memóriával rendelkezne ahhoz, hogy az összes kap- 
csolóelemhez külön bejegyzést rendelhessen. Ilyenkor 

a forgalomirányítást hierarchikusan kell végeznünk, hason- 
lóan, mint a távbeszélőhálózatok esetében. 

A hierarchikus forgalomirányítás esetén az útválasztók tar- 
tományokba vannak csoportosítva. Minden útválasztó csak 
a saját tartományába tartozó kapcsolóelemeket ismeri, 

a többi régió topológiája rejtve marad számára. Az 5. ábrán 
láthatunk egy példát az alhálózat hierarchikus felépítésére. 
Az alhálózat összesen 17 kapcsolóelemet tartalmaz, ami azt 
jelenti, hogy ha nem lenne a forgalomirányítás hierarchiku- 
san szervezett, akkor minden útválasztónak egy 17 bejegy- 
zést tartalmazó útvonalválasztó táblázatot kéne észben tar- 
tania (6/a ábra). Ellenkező esetben a tartományokat egy-egy 
csomópontba , sűríthetjük", így az útválasztóknak a lokális 
kapcsolóelemeken kívül csak tartományonként egy-egy 
bejegyzést kell tárolniuk. 

A 6. ábrán láthatunk példát az első tartományban lakó 

Az útválasztó forgalomirányító táblázatára. Az első esetben 
nincs hierarchikus forgalomirányítás, így a táblázat 17 sort 
tartalmaz. A második esetben láthatjuk, hogy a második 
tartomány felé igyekvő csomagok mindig a BD vonalon 
keresztül haladnak, míg a többi régió felé a CP vonal vezet. 
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6/b. ábra Az ,A" útválasztó táblázata hierarchikus 
forgalomirányításnál 


A táblázatok méretkülönbsége szembeötlő, a táblázat a hie- 
rarchikus forgalomirányítás esetében 17 helyett csupán 7 
bejegyzést tartalmaz. Általánosan elmondható, hogy minél 
nagyobb a tartományok száma a kapcsolóelemek számához 
viszonyítva, annál kisebb méretűek lesznek az útválasztók 
forgalomirányító táblázatai. 

Mivel semmi sincs ingyen, a helyspórolásnak is megvan 

a maga ára: le kell mondanunk arról, hogy a csomagok 
minden esetben a lehető legrövidebb úton keresztül jutnak 
célba. Maradva az 5. ábrán látható példánál, ha az Az útvá- 
lasztótól a harmadik tartományban található H útválasztó- 
hoz szeretnénk eljutni, akkor kicsit kerülni fogunk. Ugyan 
leghamarabb a második régión keresztül juthatnánk el, az 
A útválasztó mégis az ötödik tartomány felé irányít minket. 
Miért? A válasz egyszerű: lehet, hogy speciálisan a H útvá- 
lasztó felé közelebb lenne, ha a BD vonalon indulnánk el, 
de a harmadik tartomány legtöbb útválasztója mégis a CP 
vonalon keresztül érhetőek el a leghamarabb. (Megmutat- 
ható azonban, hogy a hierarchikus forgalomirányításból 
adódó többletutak általában nem számottevőek, legalábbis 
bőven az elfogadható határon belül vannak. Persze kivéte- 
lek mindig vannak). 

Az 5. ábrán egy kétszintű hierarchiára láthattunk példát. 
Az igazán nagy hálózatok esetén azonban ez sem segít 

a dolgon, a forgalomirányító táblázatok mérete továbbra 

is elftogadhatatlanul nagyok maradnak. A tartományokat 
így tovább kell bontanunk zónákra, a zónákat kerületekre, 
a kerületeket csoportokra, és így tovább. 

De vajon hány hierarchiai szintet érdemes definiálni? 
Ennek kiszámításához ismert egy összefüggés, amely sze- 
rint az optimális hierarchiai szintek száma In N, ahol N 

az alhálózatban lévő útválasztók száma. Ebben az esetben 
minden útválasztónak e " In N számú bejegyzést kell tárol- 
A következő részben továbbra is a forgalomirányítással 
foglalkozunk, de most már azt vizsgáljuk, mi a helyzet, ha 
a gépek nem otthonülő életmódot folytatnak, hanem össze- 
vissza mozognak. Ezenkívül szó lesz még a többesküldéses, 
illetve az adatszórásos forgalomirányításról. 


Garzó András 
garzorwinterware.hu 
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Szoftverjogi csiki-csuki, avagy a szoftver 
analizálás és annak határai 


A szoftverek visszafejthetőek. Ezzel vélhetően nem árultam el nagy újdonságot. 
Azzal talán annál inkább, hogy a szoftverek visszafejtése bizonyos körülmények 


között jogszerű is lehet." 


A szoftver visszafejtése 

A szerző engedélye nélkül is jogosult a program használatá- 
ra licencben vagy más módon jogosított felhasználó, vagy 
megbízottja (hiszen egy mezei felhasználó az esetek 999995 - 
ában erre úgysem lenne képes) vagy egy programozó akár 
munkaköri kötelességként is a kód többszörözésére, szükség 
esetén (vissza)fordítására egy speciális információhoz való 
hozzájutás érdekében. Ezen információ kizárólagosan azon 
célt szolgálhatja, hogy a visszafejtett szoftvert más szoftve- 
rekkel együtt tudja működtetni a felhasználó. A központi 
fogalom tehát az ,interoperabilitás" megteremtése. 


A reverse engineeriny 

Az alábbi bekezdést legjobb lesz, ha a profik átugorják, 

ez tartalmazza ugyanis annak összefoglalóját, hogy mit 

ért egy jogász a reverse engineering fogalma alatt.? 

Azon eljárást, melynek keretében a tárgykódból különfé- 
le, a továbblépéshez szükséges információkat nyernek, 
revese engineeringnek nevezzük. Ennek egyik eszköze 

a dekompiláció, ami a tárgykódnak egy fordítóprogram 
segítségével forráskódba fordítását jelenti. Ám - lévén, 
hogy rengeteg fordító (kompiláló) program létezik, — 
amennyiben a visszafordításhoz nem jó dekompiláló 
programot (azaz nem az eredeti kódolásnak megfelelőt) 
használunk, a kívánt információk helyett egy értelmetlen 
és értelmezhetetlen karaktersorhoz jutunk. Ezért általá- 
ban, (ha a fordító program , ujjlenyomata" (fingerprint) 
alapján nem képes a fordítást végző azonosítani a progra- 
mot) akkor egy alap programozási nyelvre, assembly-be 
fordítja. Ezen lehetőség bármiféle tárgykód esetében 
fennáll, ám azzal a kockázattal, hogy a szerző kommentár 
sorait nem nyerjük vissza, és az assembly csak szakember 
számára olvasható programnyelv. 

A kompilált sorokat aztán az esetleges változtatásokat köve- 
tően természetesen lehet rekompilálni, amely eljárást köve- 
tően újra tárgykódban lévő programhoz jutunk. 


: Szjt. 60. §. 
? Kritikai észrevételeket ide várok: 
agi(dabend.hu 


Linuxvilág 


A de-, rekompiláció lényegi elemei tehát egyrészt a fordítás, 
másrészt pedig egy speciális többszörözés. Ezen eljáráshoz 
való hozzájárulás tehát a szerzőknek általában nem is áll ér- 
dekükben. Ezért csak különböző előfeltételek együttállása 
esetében lehet egyáltalán szó ezen eljárások jogszerű alkal- 
mazásáról. Lássuk most ezeket. 


Az információhoz való alternatív hozzájutás hiánya 
Amennyiben a megkívánt információkhoz szabad hozzá- 
jutást biztosít a szerző, aprogramot nem kell felfejteni. 
Erre példa a GPL licencelésű a szabad szoftverek esete, 
hiszen itt kötelező jelleggel megadják a kódot magát, 
vagy azt elérhetővé teszik az Interneten 

Felmerülhet azonban kérdésként, hogy milyen tágan 
értelmezhető ,a megkívánt információt ,könnyedén 
megismerhetősége" , mint kitétel. Ide sorolja a jogiroda- 
lom a régebben nyilvánosságra hozott, ám kis kutatással 
fellelhető információkat. Ellenpéldaként viszont ide tar- 
tozhat, ha az az információt további ellenszolgáltatásért 
cserébe kínálják fel. Nem szabad elfelejteni, hogy 

a könnyen hozzáférhetőség mindig egyedi mérlegelést 
megkívánó fogalom. 

Ugyancsak kérdés, hogy kinek is áll érdekében az infor- 
mációhoz jutás biztosítása, elvárható-e a felhasználótól, 
hogy a fejlesztő felkeresésével időt töltsön, annak érdeké- 
ben, hogy a dekompiláció ne minősüljön joggal való 
visszaélésnek? Valószínűleg, rövid határidő tűzés mellett 
a fejlesztő felkeresése és felszólítása az adat szolgáltatására 
jogos elvárás. 


Az információk célhoz kötött volta 

A másik alapvető feltétel, hogy a megszerzett informá- 
ciók ténylegesen a programok együttműködtésének 
lehetőségét biztosítsák. Minden más céllal történő vissza- 
fejtés engedélyköteles. Ugyanúgy nem szabad ötletek 
megszerzése céljából dekompilálni, mint ahogy jogsér- 











tés bizonyítása sem megengedett? ezen a módon. 
(Amennyiben bíróság rendeli el a szakértő általi dekom- 
pilációt, az persze más eset, ám a bíróság jogosult a sokkal 
egyszerűbb utat is választani, kérni a forráskód kiadását.) 
Sőt a felhasználó azt sem teheti meg, hogy a szoftver hi- 
báját ezúton bizonyítja, hiszen — bár a cél nemes — még- 
sem felel meg az irányelv és a törvény szövegének, mely 
egyértelműen csak , önállóan megalkotott szoftver más 
szoftverekkel való együttes működtetéséhez szükséges 
információ megszerzés érdekében" teszi lehetővé az eljá- 
rást. A visszafejtés nem használható sem a felhasználó 
érdekeit közvetlenül szolgáló testre szabás céljából, sőt 
még kutatási célokból sem. 

Érdekes azonban, hogy a kompatibilissé tétel abban az eset- 
ben is engedélyezett, ha egy konkurens programmal akar- 
ják az adott szoftvert együttműködésre bírni. 

Ugyancsak speciális eset a hardverrel való együttműködés, 
együttműködtetés, hiszen a szöveg szó szerint csak szoftve- 
rekhez való illesztést engedi. A mai modern hardver ele- 
mek lehetővé teszik a szoftverek hardveres implementálá- 
sát, azaz szoftver feladatok hardverben történő ellátását. 
Ez pedig indokolttá tenné a dekompilálás engedélyezését 
erre az esetre is. Hiszen ennek elmaradása a piac megosz- 
tásához vezethet, ami versenyjogi aggályokat vet fel. 

A szoftvergyártók általában ellátják terméküket egy 
interface specifikációval, mely esetenként azonban nem 
teljes körű, így a visszafejtés elkerülhetetlen. Ám az abból 
nyert információk (akár az interface alkotó kódja is) 

a visszafejtő rendelkezésére állnak. Ezek közül azonban 

a szabályozás alapelvének megfelelően elsődlegesen a spe- 
cifikációt kell kiegészíteni és azt használni, nem pedig 

a konkrét kódot átemelni. 


A személyi kör 

A dekompilálás három személyt érinthet. A felhasználási 
szerződésben jogosítottat, vagy a szoftver felhasználására 
jogosult más személyt (pl.: munkaviszony alapján eljárót) 
illetve ezek megbízottját, aki semmiféle közvetlen viszony- 
ban nem áll a szerzővel. Ezen személy eljárási jogosultságát 
elég egy polgári jogi jogviszonnyal igazolni. A személyi 

kör utolsó elemmel való kibővítését az tette szükségessé, 
hogy a dekompilálás — mint már a bevezetésben említésre 
került — speciális tudást igényel. 


Az információ terjedelme 

A szükséges programrészek jelentik az információ megis- 
merésének határát. Feltétlen megismerést igénylő, tehát az 
együttműködéshez szükséges információt tartalmaznak 
például a (hivatalos és nem hivatalos?) csatlakozó felületek 
(interface). 

A dekompilációt végző személytől elvárható, hogy a kézi- 
könyvek és a rendelkezésre álló irodalom információi 
alapján kiderítse, hogy melyik programrészt kell dekom- 
pilálni. Egyes — az újabb programokra egyre jellemzőbb — 
megoldások esetében, melyek könyvtárak bevonásával 


:  Dreier: GRUR 1993 781-785 

: Ezen megkülönböztetés versenyjogilag lehet releváns, 
hiszen a nem hivatalos interface-ek arra szolgálnak, 
hogy azokat csak maga a gyártó használhassa. 
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dolgoznak ez a hely könnyebben meghatározható, 

azaz nem kell valamennyi könyvtárat visszafordítani. 
Más esetekben viszont, mikor szorosan összefüggő prog- 
ramszövegről van szó, felmerülhet a teljes fordítás elke- 
rülhetetlensége. A vizsgálat terjedelmi korlátait mindig 
speciális vizsgálat keretében kell ellenőrizni, vizsgálni 
kell, hogy adott szakértelem mellett előre látta-e vagy 
láthatta-e, hogy a program mekkora részének visszafor- 
dítása szükséges. Azonban még annak sincs kialakult 
gyakorlata, hogy a terjedelmi korlátok , túl nem lépését 
ki köteles bizonyítani. 


s 


A megismert információ szabadsága 

A szerző érdekeinek védelme szükségesé teszi, 

hogy a visszafordítás keretében elnyert információ 

ne legyen továbbadható. E védelmi szint még abban 

az esetben is fenntartandó, ha más felhasználók 
ugyancsak visszafordításokra lesznek kénytelenek, 
melyek végeredményeként természetesen ugyanazon 
eredményeket kapják. Az említett korlátozás olyannyi- 
ra kereteket jelent, hogy a megtalált interfész nem ad- 
ható közre a szakirodalomban, viszont az érem másik 
oldalaként az általunk írt szoftver kézikönyvében meg- 
jelenhet, hogy hogyan tehető kompatibilissé adott 
esetben egy operációs rendszerrel a programunk. Egyedi 
megoldás, hogy ha a szerzői oldalról visszaélést tapasz- 
talnak, vagy piacot uraló helyzet áll fenn, a kartelljogi 
szabályokra hivatkozva követelhetjük a lényeges infor- 
mációk közreadását. 
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Az utánozási tilalom 

Ismételt tilalomként jelenik meg, a nyomatékosság 
kedvéért, hogy a megszerzett ismeretek alapján nem 
lehet egy az eredetihez hasonló programot létrehozni, 
sem olyat, mely hasonló elvekre épülne, vagy hasonló 
funkciókkal lenne ellátva. Ez voltaképpen versenyjogi 
kérdésnek tekinthető. Kétségtelenül tisztességtelen piaci 
magatartást testesítene meg a fél, aki az említett módon 
hozzájutva az információkhoz kezdi meg konkurens 
szoftver terjesztését. 

Ez azonban nem jelenti azt, hogy ne lehetne - az eredeti 
használata nélkül alkotni egy másikat, hasonló céllal, hiszen 
ezen tilalom léte teljesen monopolizálttá tenné a piacot... 
egyetlen operációs rendszer működne, amin egyetlen szó- 
tárprogramot és egyetlen könyvelő programot lehetne fut- 
tatni, de mivel az ötletek nem védettek, így lehetőséget kell 
biztosítani másnak is hogy egy adott probléma megoldására 
szoftvert fejlesszen. 
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